Recentemente, migrei um pool de armazenamento de dados em massa (ZFS On Linux 0.6.2, Debian Wheezy) de uma configuração de vdev de dispositivo único para uma configuração de vdev espelho de duas vias.
A configuração anterior do pool era:
NAME STATE READ WRITE CKSUM
akita ONLINE 0 0 0
ST4000NM0033-Z1Z1A0LQ ONLINE 0 0 0
Tudo correu bem após a conclusão do resilver (iniciei uma limpeza após a conclusão do resilver, apenas para que o sistema repasse tudo de novo e verifique se tudo estava 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 o pool não era bom e agradável. Eu dei uma olhada e foi o que 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
A limpeza é esperada; existe 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 aliases que são mapeados para os nomes / dev / disk / by-id / wwn- * e, no caso de ambos, esses discos deram ao ZFS liberdade para usar o disco completo, incluindo o gerenciamento de 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 de /etc/zfs/vdev_id.conf (notei agora que o Z1Z333ZA usa um caractere de tabulação para separação, enquanto a linha Z1Z1A0LQ usa apenas espaços, mas 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.
A emissão sudo udevadm triggerfez 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 mostra como UNAVAIL). Suponho que isso possa ser esperado.
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 do 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 são conectadas diretamente à placa-mãe; não há um controlador externo envolvido.
Por impulso, eu fiz:
# zpool online akita ST4000NM0033-Z1Z333ZA
que parece ter funcionado; O Z1Z333ZA agora é pelo menos ONLINEe resistente a resiliência . Em cerca de uma hora no resilver, ele digitaliza 180G e 24G com 9,77%, o que indica que ele não realiza um resilver completo, mas apenas transfere o delta do conjunto de dados.
Sinceramente, não tenho certeza se esse problema está relacionado ao ZFS no Linux ou ao udev (ele cheira um pouco ao udev, mas por que uma unidade seria detectada muito bem, mas não a outra), mas minha pergunta é como eu faço Certifique-se de que a mesma coisa não aconteça novamente na próxima reinicialização?
Ficarei feliz em fornecer mais dados sobre a instalação, se necessário; deixe-me saber o que é necessário.
wwn-*nomes simples , o pool parece estar estável.zpool detach akita ST4000NM0033-Z1Z333ZAdepoiszpool attach -o ashift=12 -f akita ST4000NM0033-Z1Z1A0LQ wwn-0x5000c50065e8414a,zpool detach akita ST4000NM0033-Z1Z1A0LQentãozpool attach akita wwn-0x5000c50065e8414a wwn-0x5000c500645b0fec, verificando entre cada etapa que a piscina estava estável. Eu recomendo uma esfoliação completa primeiro. Você provavelmente poderia se darzpool replacebem também, mas como os apelidos apontados para os nomes do wwn e eu tinha redundância e backups, isso parecia mais seguro. Demorou alguns dias, mas eu não estava com pressa.