Eu migrei recentemente um conjunto de armazenamento de dados em massa (ZFS no Linux 0.6.2, Debian Wheezy) de uma configuração de vdev de dispositivo único para uma configuração de vdev de espelho bidirecional.
A configuração anterior do pool era:
NAME STATE READ WRITE CKSUM
akita ONLINE 0 0 0
ST4000NM0033-Z1Z1A0LQ ONLINE 0 0 0
Tudo estava bem após a conclusão do resilver (iniciei um scrub após a conclusão do resilver, apenas para que o sistema superasse tudo novamente e certificasse-se de que estava tudo bem):
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
No entanto, após a reinicialização, recebi um e-mail notificando-me do fato de que a piscina não estava bem e dandy. Eu dei uma olhada e foi isso que eu vi:
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
O scrub é esperado; Há uma configuração de tarefa cron para iniciar uma limpeza completa do sistema na reinicialização. No entanto, eu definitivamente não esperava que o novo HDD caísse do espelho.
Defino os aliases que mapeiam para os nomes / dev / disk / by-id / wwn- * e, no caso de ambos os discos terem dado acesso livre ao ZFS para usar o disco completo, incluindo o tratamento do particionamento:
# 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
#
Estas são as linhas relevantes do /etc/zfs/vdev_id.conf (eu noto agora que o Z1Z333ZA usa um caractere de tabulação para separação, enquanto a linha Z1Z1A0LQ usa apenas espaços, mas eu sinceramente não vejo como isso poderia ser relevante aqui):
alias ST4000NM0033-Z1Z1A0LQ /dev/disk/by-id/wwn-0x5000c500645b0fec
alias ST4000NM0033-Z1Z333ZA /dev/disk/by-id/wwn-0x5000c50065e8414a
Quando olhei, /dev/disk/by-id/wwn-0x5000c50065e8414a* estava lá como esperado, mas /dev/disk/by-vdev/ST4000NM0033-Z1Z333ZA* não estava.
Emitir sudo udevadm trigger fez com que os links simbólicos aparecessem em / dev / disk / by-vdev. No entanto, o ZFS parece não perceber que eles estão lá (o Z1Z333ZA ainda é exibido como UNAVAIL ). Isso eu suponho que possa ser esperado.
Eu tentei substituir o dispositivo relevante, mas não tive muita sorte:
# 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'
#
Ambos os discos são detectados durante o processo de inicialização (saída de log dmesg mostrando as unidades relevantes):
[ 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
Ambas as unidades estão conectadas diretamente à placa-mãe; não há controlador externo envolvido.
Por impulso, eu fiz:
# zpool online akita ST4000NM0033-Z1Z333ZA
que parece ter funcionado; O Z1Z333ZA agora tem pelo menos ONLINE e resilvering. Em cerca de uma hora para o resilver é escaneado 180G e resilvered 24G com 9,77% feito, o que aponta para ele não fazer um resilver completo, mas sim apenas transferir o dataset delta.
Honestamente, não tenho certeza se esse problema está relacionado ao ZFS No Linux ou no udev (cheira um pouco como o udev, mas por que uma unidade seria detectada muito bem, mas não a outra), mas minha pergunta é < Como posso garantir que a mesma coisa não aconteça novamente na próxima reinicialização?
Terei prazer em fornecer mais dados sobre a configuração, se necessário; deixe-me saber o que é necessário.