This is the old XigmaNAS forum in read only mode,
it will taken offline by the end of march 2021!



I like to aks Users and Admins to rewrite/take over important post from here into the new fresh main forum!
Its not possible for us to export from here and import it to the main forum!

réparation d'un pool ZFS après écrasement de partition

French community

Moderators: velivole18, ernie, mtiburs

Forum rules
Set-Up GuideFAQsForum Rules
Post Reply
User avatar
mtiburs
Forum Moderator
Forum Moderator
Posts: 951
Joined: 09 Aug 2012 23:34
Location: France - Besançon
Status: Offline

réparation d'un pool ZFS après écrasement de partition

Post by mtiburs »

Il m'est arrivé un petit soucis et j'ai pû m'en sortir avec de la chance ou pas ... je partage donc avec vous ce soucis ... "au cas oû"

Voilà, un jour, (mal réveillé sans doute) j'ai décidé de mettre un nouveau disque (machine du type dual-core en 775 avec 4Go de RAM et 3 disques durs mal montés (2To + 2To + 1,5To + 500Go en striping) ... je sais c'est pas bien mais ça marche (c'est pas une système en prod et si je perd tout je m'en fiche; c'est un clône d'un 3 x 2To en striping par rsync).
Je voulais également mettre cette machine en Linux/Debian avec ZOL (ZfsOnLinux).
Comme ce (nouveau) disque était en LVM, le partitionnement ne voulait pas se faire normalement, je "m'emmèle les pinceaux" et je me trompe de disque, je transforme un de mes disques en ZFS stripé en ext4 ! :(
Bon, inutile de dire que ça ne marchait plus du tout après: ZFS me dit (que lui aussi est mal réveillé et) qu'il détecte un autre système.

Cette machine était vouée a être "refaite" dans le futur (passage des 4 disques stripés à 4 pool distincts), mais j'avais "évidement" mis quelques trucs dessus dans un dataset nommé "aranger" ... que je n'avais pas encore déplacé :oops:
Je me suis donc mis en quète "d'essayer" de remettre les choses d'aplomb.

... impossible ? :mrgreen:

Je me suis dis "revenons en arrière", coupons la lumière et quand le courant reviendra, je siffloterai devant ZFS comme si de rien n'était 8-)

Donc (en partant cette fois en Linux Debian):
- Je supprime avec cfdisk ma partition en ext4, et j'écris sur le disque (je n'ai donc plus que de l'espace vide)
- Je coupe tout
- Je remets en route ... rien
- Je fais un zpool import ... ZFS me dit "pas possible !, ça va pas, y'à pas de données suffisantes"
- Je fais un zpool import -D monpool (pour rappel -D restaure un pool détruit) ... rien !
- Je fais un zpool import -f monpool ... ZFS ne veut toujours pas ... je commence a perdre espoir
- Je teste un zpool import -f -a ... ZFS se lance ... le temps passe et 1mn après ... ça marche ! le prompt réapparait sans erreur.
Là je me dis que c'est peut-être un peu "trop beau"
- un zpool status ... aucune erreur ... pas belle la vie ? hein !
J'ai lancé un scrub par sécurité car je n'y croyais pas trop, mais non, tout est ok.

J'ai pû recopier mes fichiers.

mon soucis a été mes deux disques de cacheZFS qui était /dev/da0 et /dev/da1 qui ont été impossible a supprimer car j'étais en Linux (ces noms de dev sont incorrects sous Linux).
Comme N4F fonctionne (fonctionnait) mieux que ZFS en Linux (c'est pas que ça marche pas, mais cela me semble moins efficace ... ou moins rapide, on va dire) j'installe N4F et je fais un import et ça marche aussi !
Cette fois-ci je peux supprimer mes dev/da0 et /dev/da1.

Bon bref, après tout ceci, ma machine est retourné en N4F et fonctionne bien.

Tout ceci pour dire que de supprimer le FS (partitionnement) a permis à ZFS de retrouver "ses petits"
Serveur Intel bi-Xéon P5530 / 8 X Ubuntu Serveur 18.04 LTS - ZFS-BTRFS-bcache / ~30 x PI2b(ARM) sous Nas4Free / et ...(chhhut)... 1 seul Xigmanas :o ... et pas à jour en plus :oops: (çà craint)
Conception d'un "système bizarre" :mrgreen: de "super-devices-autonomes" en NFS gérés par des micro-serveurs SAN(+nas) sous N4F (11 super-devs en raidz3) taille actuelle: 16To / prévue: 64To / théorique: 320To (consommation < 15W en veille - 24/24h) en service depuis 2 ans.

Post Reply

Return to “Français”