J'ai récemment migré un pool de stockage de données en vrac (ZFS sur Linux 0.6.2, Debian Wheezy) d'une configuration vdev à un seul périphérique vers une configuration vdev miroir bidirectionnelle.
La configuration de pool précédente était:
NAME STATE READ WRITE CKSUM
akita ONLINE 0 0 0
ST4000NM0033-Z1Z1A0LQ ONLINE 0 0 0
Tout allait bien une fois le résilver terminé (j'ai lancé un gommage après la fin du resilver, juste pour que le système revoie tout et m'assure que tout était bien):
pool: akita
state: ONLINE
scan: scrub repaired 0 in 6h26m with 0 errors on Sat May 17 06:16:06 2014
config:
NAME STATE READ WRITE CKSUM
akita ONLINE 0 0 0
mirror-0 ONLINE 0 0 0
ST4000NM0033-Z1Z1A0LQ ONLINE 0 0 0
ST4000NM0033-Z1Z333ZA ONLINE 0 0 0
errors: No known data errors
Cependant, après le redémarrage, j'ai reçu un e-mail m'informant du fait que la piscine n'était pas fine et dandy. J'ai jeté un œil et voici ce que j'ai vu:
pool: akita
state: DEGRADED
status: One or more devices could not be used because the label is missing or
invalid. Sufficient replicas exist for the pool to continue
functioning in a degraded state.
action: Replace the device using 'zpool replace'.
see: http://zfsonlinux.org/msg/ZFS-8000-4J
scan: scrub in progress since Sat May 17 14:20:15 2014
316G scanned out of 1,80T at 77,5M/s, 5h36m to go
0 repaired, 17,17% done
config:
NAME STATE READ WRITE CKSUM
akita DEGRADED 0 0 0
mirror-0 DEGRADED 0 0 0
ST4000NM0033-Z1Z1A0LQ ONLINE 0 0 0
ST4000NM0033-Z1Z333ZA UNAVAIL 0 0 0
errors: No known data errors
Le gommage est attendu; il existe une configuration de tâche cron pour lancer un nettoyage complet du système au redémarrage. Cependant, je ne m'attendais certainement pas à ce que le nouveau disque dur tombe du miroir.
Je définis des alias qui correspondent aux noms / dev / disk / by-id / wwn- *, et dans le cas de ces deux disques, ZFS a laissé libre cours à l'utilisation du disque complet, y compris la gestion du partitionnement:
# zpool history akita | grep ST4000NM0033
2013-09-12.18:03:06 zpool create -f -o ashift=12 -o autoreplace=off -m none akita ST4000NM0033-Z1Z1A0LQ
2014-05-15.15:30:59 zpool attach -o ashift=12 -f akita ST4000NM0033-Z1Z1A0LQ ST4000NM0033-Z1Z333ZA
#
Ce sont les lignes pertinentes de /etc/zfs/vdev_id.conf (je remarque maintenant que le Z1Z333ZA utilise un caractère de tabulation pour la séparation tandis que la ligne Z1Z1A0LQ utilise uniquement des espaces, mais honnêtement, je ne vois pas comment cela pourrait être pertinent ici) :
alias ST4000NM0033-Z1Z1A0LQ /dev/disk/by-id/wwn-0x5000c500645b0fec
alias ST4000NM0033-Z1Z333ZA /dev/disk/by-id/wwn-0x5000c50065e8414a
Quand j'ai regardé, j'étais /dev/disk/by-id/wwn-0x5000c50065e8414a*là comme prévu, mais ce /dev/disk/by-vdev/ST4000NM0033-Z1Z333ZA*n'était pas le cas.
L'émission a sudo udevadm triggerfait apparaître les liens symboliques dans / dev / disk / by-vdev. Cependant, ZFS ne semble pas simplement se rendre compte qu'ils sont là (Z1Z333ZA apparaît toujours comme UNAVAIL). Je suppose que cela peut être attendu.
J'ai essayé de remplacer l'appareil concerné, mais je n'ai pas eu de chance:
# zpool replace akita ST4000NM0033-Z1Z333ZA
invalid vdev specification
use '-f' to override the following errors:
/dev/disk/by-vdev/ST4000NM0033-Z1Z333ZA-part1 is part of active pool 'akita'
#
Les deux disques sont détectés pendant le processus de démarrage (sortie du journal dmesg montrant les lecteurs appropriés):
[ 2.936065] ata2: SATA link up 6.0 Gbps (SStatus 133 SControl 300)
[ 2.936137] ata4: SATA link up 6.0 Gbps (SStatus 133 SControl 300)
[ 2.937446] ata4.00: ATA-9: ST4000NM0033-9ZM170, SN03, max UDMA/133
[ 2.937453] ata4.00: 7814037168 sectors, multi 16: LBA48 NCQ (depth 31/32), AA
[ 2.938516] ata4.00: configured for UDMA/133
[ 2.992080] ata6: SATA link up 6.0 Gbps (SStatus 133 SControl 300)
[ 3.104533] ata6.00: ATA-9: ST4000NM0033-9ZM170, SN03, max UDMA/133
[ 3.104540] ata6.00: 7814037168 sectors, multi 16: LBA48 NCQ (depth 31/32), AA
[ 3.105584] ata6.00: configured for UDMA/133
[ 3.105792] scsi 5:0:0:0: Direct-Access ATA ST4000NM0033-9ZM SN03 PQ: 0 ANSI: 5
[ 3.121245] sd 3:0:0:0: [sdb] 7814037168 512-byte logical blocks: (4.00 TB/3.63 TiB)
[ 3.121372] sd 3:0:0:0: [sdb] Write Protect is off
[ 3.121379] sd 3:0:0:0: [sdb] Mode Sense: 00 3a 00 00
[ 3.121426] sd 3:0:0:0: [sdb] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
[ 3.122070] sd 5:0:0:0: [sdc] 7814037168 512-byte logical blocks: (4.00 TB/3.63 TiB)
[ 3.122176] sd 5:0:0:0: [sdc] Write Protect is off
[ 3.122183] sd 5:0:0:0: [sdc] Mode Sense: 00 3a 00 00
[ 3.122235] sd 5:0:0:0: [sdc] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
Les deux disques sont connectés directement à la carte mère; aucun contrôleur externe n'est impliqué.
Sur une impulsion, j'ai fait:
# zpool online akita ST4000NM0033-Z1Z333ZA
qui semble avoir fonctionné; Z1Z333ZA est maintenant au moins en cours de ONLINEréargenture. À environ une heure dans le resilver, il est numérisé à 180G et resilver à 24G avec 9,77% fait, ce qui indique qu'il ne fait pas un resilver complet mais plutôt que le transfert du delta de l'ensemble de données.
Honnêtement, je ne sais pas si ce problème est lié à ZFS sous Linux ou à udev (il sent un peu comme udev, mais alors pourquoi un lecteur serait-il détecté très bien mais pas l'autre), mais ma question est de savoir comment faire sûr que la même chose ne se reproduira pas au prochain redémarrage?
Je serai heureux de fournir plus de données sur la configuration si nécessaire; faites-moi juste savoir ce qui est nécessaire.
wwn-*noms nus , le pool semble être stable.