ZFS est impitoyable sur l’intégrité des données et étrangement indulgent sur tout le reste. Vous pouvez retirer un contrôleur, remplacer un backplane, réordonner des câbles, et ZFS gardera généralement vos données à l’abri. Mais il peut « oublier » où réside votre pool, parce que l’idée du système d’exploitation sur les noms de disques est… interprétative. Le /dev/sdb d’aujourd’hui peut devenir le /dev/sde de demain, et le pool qui s’importait automatiquement vous regarde désormais comme s’il ne vous connaissait pas.
C’est là que zpool import -d prend tout son sens. Ce n’est pas de la magie ; c’est simplement indiquer à ZFS où chercher des nœuds de périphérique (ou des fichiers) susceptibles de contenir des membres de pool. L’astuce consiste à savoir quel répertoire lui donner, ce qu’il fait avec ce répertoire, et comment interpréter les résultats sous pression — par exemple quand un VP demande pourquoi le « lac de données » ressemble actuellement à un « mirage de données ».
Ce que fait réellement zpool import -d
zpool import est l’outil de ZFS pour « trouver les pools qui existent mais ne sont pas actuellement importés ». Lorsque vous l’exécutez sans arguments, il recherche un ensemble par défaut d’emplacements pour des périphériques susceptibles de contenir des labels ZFS (les métadonnées au début/à la fin de chaque vdev).
zpool import -d <dir> change la portée de la recherche. Vous dites à ZFS : « Cherche dans ce répertoire des périphériques bloc (ou des fichiers) qui peuvent contenir des labels ZFS. » Il parcourra les entrées sous ce répertoire, ouvrira les périphériques, lira les labels et tentera d’assembler des pools candidats.
Comportements clés utiles en production
-dconcerne l’endroit où chercher, pas ce qu’il faut importer. Il influence la découverte. L’import suit toujours les règles normales (vérifications hostid/pool actif, comportement des points de montage, etc.).- Vous pouvez spécifier plusieurs options
-d. C’est précieux quand vous avez un mélange de/dev/disk/by-id, de périphériques multipath, ou de répertoires de staging. -dpeut pointer vers un répertoire de fichiers. Oui : importer des pools depuis des fichiers image (pour la forensique ou des restaurations en labo) est une pratique réelle.- La découverte peut être ralentie par un « trop grand répertoire ». Pointer vers
/devsur un système avec beaucoup de nœuds de périphérique, des maps multipath obsolètes ou des montages de conteneurs bizarres peut transformer un « scan rapide » en « pourquoi ça bloque ».
Blague #1 : Si vous avez déjà fait confiance aux noms /dev/sdX en production, soit vous êtes très courageux soit vous n’avez jamais redémarré.
Pourquoi les chemins de périphérique changent (et pourquoi ZFS s’en soucie)
Les noms de périphériques bloc Linux comme /dev/sda sont attribués selon l’ordre de découverte. Cet ordre change parce que le monde change : timings du firmware différents, réinitialisations HBA, mises à jour du noyau, un disque qui met plus de temps à tourner aujourd’hui, une ré-enumération du bus PCIe, ou multipath prenant d’abord une route différente.
ZFS stocke l’identité des vdev dans des labels en utilisant des identifiants stables quand ils sont disponibles, mais il a quand même besoin que le système OS présente un nœud de périphérique qu’il puisse ouvrir et lire. Si votre pool a été créé sur /dev/sdb et que plus tard vous avez configuré cachefile ou des services systemd s’attendant à ces chemins, vous pouvez vous retrouver avec un démarrage qui n’importera pas automatiquement ou un import qui utilise un chemin inattendu.
Familles de chemins courantes que vous rencontrerez
/dev/sdX: court, pratique, et instable au fil des redémarrages et des changements de topologie./dev/disk/by-id/: stable, basé sur WWN/numéro de série ; préféré pour les serveurs./dev/disk/by-path/: relativement stable, décrit le chemin bus ; peut changer si vous déplacez des câbles ou des HBA./dev/mapper/mpath*: périphériques multipath ; stables mais nécessitent une configuration multipath correcte (et de la discipline)./dev/zvol/: volumes ZFS présentés comme périphériques bloc ; non pertinents pour l’import mais souvent confondus lors des incidents.
Faits intéressants et contexte historique
Un peu de contexte rend le comportement étrange d’aujourd’hui moins aléatoire — et vous aide à l’expliquer à ceux qui pensent que le stockage, c’est « juste des disques ».
- ZFS écrit plusieurs labels par périphérique. Les labels sont écrits au début et à la fin de chaque membre de vdev, ce qui augmente la résilience face aux écritures partielles et rend la découverte possible même quand une extrémité est endommagée.
- Le design initial de ZFS privilégiait l’auto-description. Les pools se décrivent eux-mêmes : topologie, GUIDs de vdev et config sont embarqués sur disque, pas dans une base de données séparée de gestionnaire de volumes.
- La vérification « hostid » existe pour empêcher d’importer un pool actif ailleurs. C’est une sécurité contre le split-brain et les désastres de double montage.
- Le nommage
/dev/sdXn’est pas fait pour être stable. Linux le traite comme un détail d’implémentation, pas comme un contrat d’interface. C’est pour ça que udev propose by-id/by-path. - ZFS est antérieur à beaucoup d’attentes actuelles du démarrage Linux. Nombre de problèmes « ZFS n’a pas importé au démarrage » sont en réalité liés à l’ordre d’initialisation, aux timings udev ou à la gestion du cachefile — les stacks de boot modernes sont rapides, et le stockage parfois pas.
- Multipath peut faire paraître un import « hanté ». Si les chemins bruts et les maps multipath coexistent, ZFS peut voir des doublons. Votre pool peut être « importable » deux fois, et aucune des deux options n’est celle que vous voulez.
- L’import en lecture seule est une fonctionnalité intentionnelle. Elle permet une forensique sûre et réduit le risque quand vous n’êtes pas sûr que le pool ait été exporté proprement.
- ZFS peut importer des pools depuis des fichiers ordinaires. Ce n’est pas un tour de passe-passe ; c’est la méthode que beaucoup de labos utilisent pour tester des upgrades et ce que certaines équipes d’incidents font pour des vérifications rapides hors ligne.
Playbook de diagnostic rapide
Quand un pool « disparaît » après un changement de chemins, votre objectif est de répondre rapidement à trois questions : (1) les disques sont-ils visibles, (2) les labels ZFS sont-ils lisibles, et (3) quelque chose bloque-t-il l’import (hostid, usage actif, multipath, vdevs manquants).
Première étape : confirmer que l’OS voit le matériel que vous pensez voir
cr0x@server:~$ lsblk -o NAME,TYPE,SIZE,MODEL,SERIAL,WWN,FSTYPE,MOUNTPOINTS
NAME TYPE SIZE MODEL SERIAL WWN FSTYPE MOUNTPOINTS
sda disk 1.8T HGST_HUS724... K7J1... 0x5000cca25...
sdb disk 1.8T HGST_HUS724... K7J2... 0x5000cca25...
nvme0n1 disk 3.6T SAMSUNG_MZ... S4EV... 0x0025385... Interprétation : si les WWN/numéros de série attendus ne sont pas présents, ce n’est pas encore un problème ZFS. C’est un problème de câblage, HBA, expander, multipath, ou disque mort. Si les disques sont présents mais que les noms ont changé, poursuivez.
Deuxième étape : vérifier ce que ZFS considère importable
cr0x@server:~$ sudo zpool import
pool: tank
id: 12345678901234567890
state: ONLINE
action: The pool can be imported using its name or numeric identifier.
config:
tank ONLINE
raidz1-0 ONLINE
/dev/sdb ONLINE
/dev/sdc ONLINE
/dev/sdd ONLINEInterprétation : si ceci affiche des chemins /dev/sdX auxquels vous ne faites plus confiance, vous pouvez toujours importer — mais vous devriez corriger le nommage persistant immédiatement après. Si rien n’apparaît, vous aurez probablement besoin de -d pour indiquer à ZFS le bon namespace.
Troisième étape : chercher dans le namespace stable et repérer les doublons
cr0x@server:~$ sudo zpool import -d /dev/disk/by-id
pool: tank
id: 12345678901234567890
state: ONLINE
action: The pool can be imported using its name or numeric identifier.
config:
tank ONLINE
raidz1-0 ONLINE
wwn-0x5000cca25abcd001 ONLINE
wwn-0x5000cca25abcd002 ONLINE
wwn-0x5000cca25abcd003 ONLINEInterprétation : c’est ce que vous voulez. Si cela apparaît aussi via /dev/sdX ou via /dev/mapper, arrêtez-vous et décidez quelle couche est autoritaire. Importer via la mauvaise couche est la façon la plus sûre d’acheter un week-end.
Quatrième étape : si l’import est bloqué, identifiez la raison avant de forcer
cr0x@server:~$ sudo zpool import tank
cannot import 'tank': pool may be in use from other system
use '-f' to import anywayInterprétation : n’ajoutez pas réflexivement -f. Confirmez que le pool n’est pas réellement importé ailleurs (ou n’a pas été exporté proprement) et assurez-vous de ne pas voir les mêmes LUNs via deux chemins (les erreurs de zoning SAN arrivent).
Tâches pratiques : commandes + interprétation
Ci-dessous les tâches que j’exécute réellement sur le terrain. Chacune a une raison, une commande, et la façon de lire le résultat. Utilisez-les comme blocs de construction.
Tâche 1 : Montrer les pools importables et les chemins de périphérique que ZFS voit actuellement
cr0x@server:~$ sudo zpool import
pool: backup
id: 8811223344556677889
state: DEGRADED
status: One or more devices could not be opened.
action: The pool can be imported despite missing devices.
see: http://zfsonlinux.org/msg/ZFS-8000-2Q
config:
backup DEGRADED
mirror-0 DEGRADED
/dev/sda ONLINE
15414153927465090721 UNAVAILInterprétation : ZFS vous indique qu’un périphérique identifié par GUID est manquant. Ce n’est pas « renommage de périphérique » ; c’est « périphérique absent » (ou présent sous un namespace différent que vous n’avez pas scanné).
Tâche 2 : Chercher un répertoire spécifique pour les périphériques (bases de -d)
cr0x@server:~$ sudo zpool import -d /dev/disk/by-id
pool: backup
id: 8811223344556677889
state: ONLINE
action: The pool can be imported using its name or numeric identifier.
config:
backup ONLINE
mirror-0 ONLINE
wwn-0x5000c500a1b2c3d4 ONLINE
wwn-0x5000c500a1b2c3e5 ONLINEInterprétation : le disque « manquant » était en fait présent ; vous ne cherchiez tout simplement pas au bon endroit.
Tâche 3 : Utiliser plusieurs -d pour couvrir les environnements mixtes
cr0x@server:~$ sudo zpool import -d /dev/disk/by-id -d /dev/mapper
pool: sanpool
id: 4000111122223333444
state: ONLINE
action: The pool can be imported using its name or numeric identifier.
config:
sanpool ONLINE
mirror-0 ONLINE
mpatha ONLINE
mpathb ONLINEInterprétation : si votre stockage est multipathé, préférez importer via /dev/mapper/mpath* ou via by-id pour le périphérique multipath, pas via les chemins bruts /dev/sdX. La cohérence compte plus que les préférences.
Tâche 4 : Détecter les présentations en double de périphériques (chemins bruts vs multipath)
cr0x@server:~$ ls -l /dev/disk/by-id | grep -E 'wwn|dm-uuid|mpath' | head
lrwxrwxrwx 1 root root 9 Dec 25 09:10 dm-uuid-mpath-3600508b400105e210000900000490000 -> ../../dm-2
lrwxrwxrwx 1 root root 9 Dec 25 09:10 mpath-3600508b400105e210000900000490000 -> ../../dm-2
lrwxrwxrwx 1 root root 9 Dec 25 09:10 wwn-0x600508b400105e210000900000490000 -> ../../sdbInterprétation : si le même LUN apparaît comme dm-* et sd*, vous devez décider lequel ZFS doit utiliser. Importer avec les périphériques bruts sd* alors que multipath est actif est la meilleure manière d’inviter des erreurs I/O intermittentes et des basculements de chemin dans votre pool.
Tâche 5 : Regarder directement les labels ZFS (vérification)
cr0x@server:~$ sudo zdb -l /dev/disk/by-id/wwn-0x5000cca25abcd001 | head -n 25
------------------------------------
LABEL 0
------------------------------------
version: 5000
name: 'tank'
state: 0
txg: 1234567
pool_guid: 12345678901234567890
vdev_guid: 11112222333344445555
top_guid: 66667777888899990000
guid: 11112222333344445555Interprétation : si zdb -l peut lire un label, la découverte devrait fonctionner. Si ce n’est pas le cas, vous avez peut-être un problème de permissions sur le périphérique, un disque en train de mourir, ou vous pointez sur la mauvaise chose (partition vs disque entier, mapper vs brut).
Tâche 6 : Importer par ID numérique (utile quand les noms se chevauchent ou sont confus)
cr0x@server:~$ sudo zpool import
pool: tank
id: 12345678901234567890
state: ONLINE
action: The pool can be imported using its name or numeric identifier.
cr0x@server:~$ sudo zpool import -d /dev/disk/by-id 12345678901234567890Interprétation : importer par ID évite les erreurs quand quelqu’un a renommé des pools de façon incohérente entre environnements (oui, ça arrive).
Tâche 7 : Importer en lecture seule pour inspecter en sécurité
cr0x@server:~$ sudo zpool import -o readonly=on -d /dev/disk/by-id tank
cr0x@server:~$ zpool status tank
pool: tank
state: ONLINE
config:
NAME STATE READ WRITE CKSUM
tank ONLINE 0 0 0
raidz1-0 ONLINE 0 0 0
wwn-0x5000cca25abcd001 ONLINE 0 0 0
wwn-0x5000cca25abcd002 ONLINE 0 0 0
wwn-0x5000cca25abcd003 ONLINE 0 0 0Interprétation : l’import en lecture seule est une manière à faible risque de confirmer que vous avez trouvé le bon pool et qu’il est sain avant d’autoriser les services à l’utiliser.
Tâche 8 : Importer sans monter les datasets (contrôler le périmètre)
cr0x@server:~$ sudo zpool import -N -d /dev/disk/by-id tank
cr0x@server:~$ zfs list -o name,mountpoint,canmount -r tank | head
NAME MOUNTPOINT CANMOUNT
tank /tank on
tank/home /home on
tank/pg /var/lib/pg onInterprétation : -N importe le pool mais ne monte pas les datasets. C’est idéal quand vous voulez définir des propriétés, vérifier des clés de chiffrement, ou éviter de démarrer une base qui paniquera immédiatement à cause de dépendances réseau manquantes.
Tâche 9 : Montrer les chemins de vdev que ZFS utilisera après import (et les corriger)
cr0x@server:~$ zpool status -P tank
pool: tank
state: ONLINE
config:
NAME STATE READ WRITE CKSUM
tank ONLINE 0 0 0
raidz1-0 ONLINE 0 0 0
/dev/sdb ONLINE 0 0 0
/dev/sdc ONLINE 0 0 0
/dev/sdd ONLINE 0 0 0Interprétation : -P affiche les chemins complets. Si vous voyez /dev/sdX, décidez si vous pouvez le tolérer. Dans la plupart des environnements, la réponse est non.
Pour migrer vers le nommage stable by-id, vous exportez et réimportez généralement en utilisant les chemins désirés :
cr0x@server:~$ sudo zpool export tank
cr0x@server:~$ sudo zpool import -d /dev/disk/by-id tank
cr0x@server:~$ zpool status -P tank | sed -n '1,25p'
pool: tank
state: ONLINE
config:
NAME STATE READ WRITE CKSUM
tank ONLINE 0 0 0
raidz1-0 ONLINE 0 0 0
/dev/disk/by-id/wwn-0x5000cca25abcd001 ONLINE 0 0 0
/dev/disk/by-id/wwn-0x5000cca25abcd002 ONLINE 0 0 0
/dev/disk/by-id/wwn-0x5000cca25abcd003 ONLINE 0 0 0Interprétation : c’est la méthode la plus simple de stabiliser les chemins : changez la découverte d’import et laissez ZFS enregistrer les chemins choisis.
Tâche 10 : Gérer « pool may be in use » en sécurité (hostid / import forcé)
cr0x@server:~$ sudo zpool import -d /dev/disk/by-id tank
cannot import 'tank': pool may be in use from other system
use '-f' to import anywayInterprétation : fréquent après avoir déplacé des disques vers un nouvel hôte, restauré une VM depuis un snapshot, ou après un arrêt non propre où l’ancien système n’a jamais exporté le pool.
Si vous êtes certain que le pool n’est pas activement importé ailleurs, forcez l’import :
cr0x@server:~$ sudo zpool import -f -d /dev/disk/by-id tankInterprétation : le flag -f contourne la vérification host. Utilisez-le comme une tronçonneuse : efficace, mais seulement quand vous la tenez correctement.
Tâche 11 : Se remettre d’un cachefile manquant / hypothèses erronées sur le cachefile
cr0x@server:~$ sudo zpool get cachefile tank
NAME PROPERTY VALUE SOURCE
tank cachefile /etc/zfs/zpool.cache local
cr0x@server:~$ ls -l /etc/zfs/zpool.cache
ls: cannot access '/etc/zfs/zpool.cache': No such file or directoryInterprétation : certaines distributions comptent sur un cachefile pour l’auto-import au démarrage. Si le fichier est manquant ou obsolète, le pool peut ne pas s’importer automatiquement même si un import manuel fonctionne bien.
Après avoir importé le pool, régénérez le cachefile :
cr0x@server:~$ sudo zpool set cachefile=/etc/zfs/zpool.cache tank
cr0x@server:~$ sudo zpool export tank
cr0x@server:~$ sudo zpool import -d /dev/disk/by-id tankInterprétation : exporter et réimporter provoque la mise à jour du cachefile de manière cohérente sur de nombreux systèmes. (L’intégration exacte au boot varie, mais le schéma tient.)
Tâche 12 : Importer quand des partitions sont impliquées (confusion disque entier vs partition)
cr0x@server:~$ lsblk -o NAME,SIZE,TYPE,FSTYPE /dev/sdb
NAME SIZE TYPE FSTYPE
sdb 1.8T disk
sdb1 1.8T part zfs_member
cr0x@server:~$ sudo zpool import -d /dev/disk/by-id tankInterprétation : si votre pool a été construit sur des partitions, assurez-vous de scanner un répertoire qui inclut les symlinks de partition (by-id le fait généralement). Si vous pointez -d vers un répertoire contenant seulement des nœuds de disque entier alors que les labels sont sur ...-part1, la découverte peut échouer.
Tâche 13 : Importer un pool à partir de fichiers image (déplacement labo/forensique)
cr0x@server:~$ sudo mkdir -p /srv/zfs-images
cr0x@server:~$ sudo losetup -fP /srv/zfs-images/disk0.img
cr0x@server:~$ sudo losetup -fP /srv/zfs-images/disk1.img
cr0x@server:~$ losetup -a | grep zfs-images
/dev/loop0: [2065]:12345 (/srv/zfs-images/disk0.img)
/dev/loop1: [2065]:12346 (/srv/zfs-images/disk1.img)
cr0x@server:~$ sudo zpool import -d /dev/ tanklab
cannot import 'tanklab': no such pool available
cr0x@server:~$ sudo zpool import -d /dev/loop tanklabInterprétation : les périphériques loop restent des périphériques. Scannez là où ils résident. Cela montre pourquoi -d est conceptuellement « où chercher », pas « quel type de disque ».
Tâche 14 : Quand l’import est lent ou semble bloqué, restreindre le scan
cr0x@server:~$ time sudo zpool import -d /dev
^C
cr0x@server:~$ time sudo zpool import -d /dev/disk/by-id
real 0m1.214s
user 0m0.084s
sys 0m0.190sInterprétation : scanner /dev est le geste « je panique ». Ça peut marcher, mais ça coûte. Les namespaces stables sont plus rapides et moins sujets aux erreurs.
Trois micro-histoires du monde de l’entreprise
Micro-histoire 1 : L’incident causé par une mauvaise hypothèse
L’interruption n’a pas commencé avec ZFS. Elle a commencé avec une mise à jour matérielle bien intentionnée : de nouveaux HBA avec un firmware plus récent, installés pendant une fenêtre de maintenance qui était « définitivement suffisante ». Le système est revenu, l’OS a démarré, et le dashboard de supervision est devenu rouge parce que le pool principal ne s’est jamais importé.
L’ingénieur on-call s’est connecté et a vu que les disques étaient présents. Ils n’étaient plus /dev/sd[bcd...] ; ils étaient /dev/sd[fgh...]. C’est normal. La mauvaise hypothèse était que « normal » signifiait aussi « sans conséquence ». L’unité d’auto-import avait été construite autour d’attentes obsolètes : un cachefile référant d’anciens chemins, plus un script personnalisé qui greppait des nœuds /dev/sdX spécifiques comme si c’était 2009.
Sous pression, quelqu’un a lancé zpool import -f tank sans préciser -d, qui a importé via le premier ensemble de périphériques que ZFS a trouvé. Malheureusement, multipath avait aussi été activé dans la nouvelle configuration, et le pool a été importé en utilisant les chemins bruts /dev/sdX alors que l’équipe SAN s’attendait à /dev/mapper/mpath*. Tout semblait correct jusqu’à ce qu’un basculement de chemin survienne — alors la latence I/O a grimpé et des erreurs de checksum sont apparues, parce que le système jonglait désormais entre des couches de périphériques incohérentes.
Le correctif a été ennuyeusement banal : exporter le pool, l’importer en utilisant le namespace prévu (/dev/mapper dans cet environnement), régénérer le cachefile, et supprimer le script personnalisé. Le post-mortem a été plus piquant : si votre automatisation dépend de /dev/sdX, vous n’avez pas d’automatisation ; vous avez une minuterie.
Micro-histoire 2 : L’optimisation qui s’est retournée contre eux
Une autre équipe voulait des démarrages plus rapides. On leur avait dit que l’import ZFS pouvait ajouter des secondes, et les secondes seraient apparemment inacceptables quand vous exécutez des microservices qui prennent des minutes à devenir utiles. Ils ont donc « optimisé » en retirant les règles disk-by-id de leur initramfs et en comptant sur une découverte simplifiée des périphériques, en supposant que le pool apparaîtrait toujours sous un chemin prévisible.
Cela a fonctionné — jusqu’à ce que ça ne fonctionne plus. Une petite mise à jour du noyau a changé le timing de l’énumération des périphériques. Les membres du pool sont apparus, mais pas à temps pour l’étape d’import. Le boot a continué sans le pool, les services se sont lancés en pointant vers des répertoires vides, et le nœud a été marqué « healthy » parce que les vérifications de santé étaient au niveau applicatif, pas stockage. On sentait le rayon d’impact : des conteneurs écrivaient joyeusement sur la racine, la remplissant, tandis que le vrai dataset restait démonté comme un témoin silencieux.
Quand l’équipe a essayé de réparer, ils ont lancé zpool import -d /dev parce que ça « couvre tout ». Sur cet hôte, « tout » incluait des centaines de nœuds de périphériques provenant de runtimes de conteneurs et un fouillis d’entrées mapper obsolètes. Les scans d’import sont devenus lents, des timeouts se sont accumulés, et le runbook de récupération est devenu un livre dont vous êtes le héros.
La solution finale a été de défaire l’optimisation : restaurer le nommage udev stable dans l’environnement de boot précoce, importer en utilisant /dev/disk/by-id, et ajouter une barrière stricte pour que les services ne démarrent pas sauf si les datasets ZFS sont montés. Les démarrages ont perdu quelques secondes ; les incidents ont été réduits de plusieurs heures. Le compromis est devenu évident après qu’un responsable ait vécu l’expérience.
Micro-histoire 3 : La pratique ennuyeuse mais correcte qui a sauvé la situation
La récupération ZFS la plus calme que j’ai vue s’est produite dans une entreprise qui traitait le stockage comme un système aéronautique : sans glamour, checklisté, et sans jamais faire confiance au « savoir tribal ». Ils avaient une règle : chaque pool doit être importé en utilisant les chemins by-id, et chaque système doit avoir une procédure d’export vérifiée avant tout déplacement de matériel.
Pendant une migration de datacenter, un châssis a été éteint, des disques déplacés, et remis sous tension. Comme prévu, les noms de périphériques ont changé. Et comme prévu, personne ne s’en est préoccupé. Le runbook disait : vérifier les disques par WWN, lancer zpool import -d /dev/disk/by-id, importer avec -N, vérifier l’état, puis monter les datasets. Ils l’ont suivi.
Ils ont rencontré un accroc : le pool indiquait « may be in use from other system ». Au lieu de forcer immédiatement, ils ont vérifié si l’ancien nœud avait encore accès via une zone SAN persistante. C’était le cas. Ils ont retiré la zone, attendu la disparition des chemins, puis importé proprement — sans forcer.
La meilleure partie était le ton dans le canal d’incident. Pas de drame, pas d’héroïsme, pas de « essayez ce flag au hasard ». Juste une séquence lente et correcte. C’était ennuyeux dans le bon sens du terme. Blague #2 : Leur runbook stockage était si soporifique qu’il pouvait soigner l’insomnie — sauf si vous aimez dormir pendant les incidents.
Erreurs courantes (avec symptômes et correctifs)
Erreur 1 : Scanner /dev et espérer le meilleur
Symptôme : zpool import -d /dev est lent, semble bloqué, ou renvoie des doublons confus.
Correctif : scannez uniquement les namespaces stables : /dev/disk/by-id pour les disques locaux, /dev/mapper pour le multipath. Utilisez plusieurs -d si nécessaire.
cr0x@server:~$ sudo zpool import -d /dev/disk/by-id -d /dev/mapperErreur 2 : Importer via des chemins bruts quand multipath est activé
Symptôme : le pool s’importe, mais montre ensuite des erreurs I/O intermittentes, des basculements de chemin, ou des sautes de performance lors d’un basculement de contrôleur.
Correctif : assurez-vous que ZFS ne voit que les périphériques multipath (blacklistez les chemins bruts dans la config multipath si approprié), puis exportez/importez en utilisant /dev/mapper/mpath* (ou le by-id correspondant aux périphériques dm).
Erreur 3 : Utiliser -f comme première réaction
Symptôme : le message pool may be in use from other system apparaît ; l’opérateur force l’import sans vérifier l’exclusivité.
Correctif : confirmez que l’ancien hôte est arrêté ou n’a plus accès aux disques/LUNs. Si c’est un SAN, vérifiez le zoning/masking. Si c’est une VM, confirmez que vous n’avez pas attaché les mêmes disques virtuels à deux invités.
Erreur 4 : Confondre « disque manquant » avec « mauvais répertoire scanné »
Symptôme : zpool import montre un vdev en UNAVAIL par GUID, mais lsblk montre le disque présent.
Correctif : scannez le namespace qui inclut le nœud réel contenant les labels ZFS (partition vs disque entier). Essayez -d /dev/disk/by-id et vérifiez avec zdb -l.
Erreur 5 : Importer et monter tout immédiatement
Symptôme : après l’import, les services démarrent trop tôt ou les datasets se montent à des endroits inattendus, provoquant une corruption applicative ou des incidents « écriture sur la racine ».
Correctif : importez avec -N, inspectez, définissez les propriétés nécessaires, puis montez délibérément.
cr0x@server:~$ sudo zpool import -N -d /dev/disk/by-id tankErreur 6 : Croire que le cachefile est une vérité absolue
Symptôme : le pool s’importe manuellement mais pas au démarrage ; ou s’importe avec des chemins étranges après des upgrades/déplacements.
Correctif : régénérez le cachefile après import avec les chemins souhaités ; assurez-vous que l’init system utilise la bonne localisation de cachefile pour votre distro.
Listes de contrôle / plan étape par étape
Plan étape par étape : récupération « pool manquant après reboot »
- Confirmer la visibilité du matériel : vérifiez les WWN/numéros de série attendus.
- Scanner le namespace stable : utilisez
zpool import -d /dev/disk/by-id. - Si multipath : assurez-vous d’importer via
/dev/mapper, pas via les chemins bruts. - Importer en sécurité d’abord : utilisez
-o readonly=onou-Nselon la situation. - Vérifier la santé :
zpool status, confirmez l’absence de vdevs inattendus manquants. - Rendre les chemins persistants : exporter et réimporter via by-id/mapper ; régénérer le cachefile.
- Monter les datasets volontairement : puis démarrer les services.
Checklist : Avant de déplacer des disques vers un nouvel hôte
- Exporter le pool proprement (
zpool export) et confirmer qu’il a disparu (zpool listne doit plus l’afficher). - Enregistrer la topologie du pool : sauvegarder la sortie de
zpool status -Pdans votre ticket. - Enregistrer les WWN :
lsblk -o NAME,SERIAL,WWN. - Sur l’hôte cible, confirmer que ces WWN apparaissent avant de tenter l’import.
- Importer avec un
-dexplicite pointant vers le namespace choisi.
Checklist : Décider de votre politique « chemin unique autoritaire »
- SATA/SAS local : préférer
/dev/disk/by-id/wwn-*ou by-id basé sur le numéro de série. - SAN avec multipath : préférer
/dev/mapper/mpath*ou by-id basé sur dm-uuid pointant vers les périphériques dm. - Éviter : les
/dev/sdXbruts dans tout environnement ayant une fenêtre de changement plus longue qu’une pause café.
FAQ
1) Qu’est-ce que zpool import -d scanne exactement ?
Il scanne les nœuds de périphérique (ou les fichiers) trouvés sous le répertoire que vous spécifiez, à la recherche des labels ZFS. Pensez « chemin de recherche pour potentiels membres de vdev ». Il ne scanne pas récursivement tout votre système de fichiers — juste les entrées dans ce namespace de répertoire.
2) Dois-je toujours utiliser /dev/disk/by-id ?
Pour les disques locaux, oui dans la plupart des environnements de production. C’est stable à travers les redémarrages et les changements d’énumération de contrôleur. Pour le SAN/multipath, /dev/mapper est souvent la couche correcte. L’important est de choisir une option et de s’y tenir.
3) Pourquoi zpool import montre-t-il parfois des GUID au lieu des noms de périphérique ?
Quand un vdev ne peut pas être ouvert, ZFS revient au GUID du vdev depuis la configuration sur disque. C’est un indice : ZFS sait ce qu’il veut, mais l’OS ne le présente pas au chemin tenté (ou pas du tout).
4) Est-il sûr d’exécuter zpool import -f ?
Ça peut être sûr si vous êtes certain que le pool n’est pas actif ailleurs. C’est dangereux si les mêmes disques/LUNs sont accessibles depuis un autre hôte qui pourrait aussi les importer. Confirmez l’exclusivité avant.
5) Pourquoi l’import fonctionne manuellement mais pas au démarrage ?
Habituellement : timing de découverte des périphériques (les disques apparaissent après la tentative d’import), cachefile manquant/obsolète, ou ordre d’initialisation. L’import manuel se fait plus tard, après que udev et le stockage se soient stabilisés.
6) Puis-je utiliser zpool import -d pour importer un pool construit sur des partitions ?
Oui, tant que le répertoire que vous scannez inclut les nœuds/symlinks de partition (par exemple ...-part1 dans by-id). Si vous scannez un répertoire ne contenant que des nœuds de disque entier alors que le pool vit sur des partitions, la découverte peut échouer.
7) Quelle est la différence entre zpool import -d et corriger définitivement les noms de périphériques ?
-d est un indice de découverte pour cette tentative d’import. La stabilité permanente vient de l’import cohérent en utilisant des chemins stables (by-id/mapper) et en s’assurant que votre processus de boot et le cachefile sont alignés avec cela.
8) Pourquoi l’import montre-t-il parfois le même pool deux fois ?
Parce que le même stockage sous-jacent est visible via plusieurs couches de périphériques (chemins bruts et multipath, ou plusieurs namespaces de symlink). C’est un signal pour s’arrêter et choisir la couche voulue avant d’importer.
9) Comment confirmer qu’un disque spécifique fait partie du pool avant l’import ?
Utilisez zdb -l sur le périphérique candidat pour lire son label et confirmer que le nom et le GUID du pool correspondent à ce que vous attendez.
Conclusion
zpool import -d est la manière pour ZFS de dire : « Dites-moi où sont les périphériques aujourd’hui, et je m’occupe du reste. » Dans un monde où les noms de périphériques sont attribués par timing et caprice, être explicite sur les chemins de découverte n’est pas optionnel — c’est la façon de garder la récupération prévisible.
Quand les chemins changent, ne paniquez pas. Confirmez que les disques existent, scannez le bon namespace, importez en sécurité (-N ou lecture seule), puis rendez la correction durable en standardisant sur des chemins stables et en gardant votre processus de boot/import honnête. Si vous faites cela, les renommages de périphériques deviendront une note de bas de page plutôt qu’un titre.