Recentemente migrei um pool de armazenamento de dados em massa (ZFS no Linux 0.6.2, Debian Wheezy) de uma configuração vdev de dispositivo único para uma configuração 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 ficou bem após a conclusão do resilver (iniciei uma limpeza após a conclusão do resilver, apenas para que o sistema revisse tudo novamente e tivesse certeza 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 boa e elegante. Dei uma olhada e foi isso 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 esfoliação é esperada; 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.
Eu defino aliases que mapeiam para os nomes /dev/disk/by-id/wwn-* e, no caso de ambos os discos, deram liberdade ao ZFS para usar o disco completo, incluindo o manuseio 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 de /etc/zfs/vdev_id.conf (percebo agora que o Z1Z333ZA usa um caractere de tabulação para separação, enquanto a linha Z1Z1A0LQ usa apenas espaços, mas honestamente 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*estavam lá como esperado, mas /dev/disk/by-vdev/ST4000NM0033-Z1Z333ZA*não estavam.
A emissão sudo udevadm triggerfez com que os links simbólicos aparecessem em/dev/disk/by-vdev. No entanto, o ZFS não parece apenas perceber que eles estão lá (Z1Z333ZA ainda aparece como UNAVAIL). Isso eu suponho que pode 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 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
o que parece ter funcionado; Z1Z333ZA agora está pelo menos ONLINEresilvering. Cerca de uma hora após o início do resilver, ele digitalizou 180G e resilverou 24G com 9,77% concluído, o que indica que ele não fez um resilver completo, mas apenas transferiu o delta do conjunto de dados.
Sinceramente, não tenho certeza se esse problema está relacionado ao ZFS no Linux ou ao udev (cheira um pouco como udev, mas então por que uma unidade seria detectada perfeitamente, mas a outra não), 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; apenas deixe-me saber o que é necessário.
Responder1
Este é um problema do udev que parece serespecífico para variantes Debian e Ubuntu. A maior parte do meu trabalho com ZFS no Linux é com CentOS/RHEL.
Tópicos semelhantes na lista de discussão do ZFS mencionaram isso.
Ver:
Entradas scsi e ata para o mesmo disco rígido em /dev/disk/by-id
e
ZFS no Linux/Ubuntu: Ajuda para importar um zpool após a atualização do Ubuntu de 13.04 para 13.10, os IDs dos dispositivos foram alterados
Não tenho certeza de qual é a abordagem de dispositivo de pool mais determinística para sistemas Debian/Ubuntu. Para RHEL, prefiro usar WWNs de dispositivos em dispositivos de pool geral. Mas outras vezes, o nome/série do dispositivo também é útil. Mas udevdeveser capaz de manter tudo isso sob controle.
# zpool status
pool: vol1
state: ONLINE
scan: scrub repaired 0 in 0h32m with 0 errors on Sun Feb 16 17:34:42 2014
config:
NAME STATE READ WRITE CKSUM
vol1 ONLINE 0 0 0
mirror-0 ONLINE 0 0 0
wwn-0x500000e014609480 ONLINE 0 0 0
wwn-0x500000e0146097d0 ONLINE 0 0 0
mirror-1 ONLINE 0 0 0
wwn-0x500000e0146090c0 ONLINE 0 0 0
wwn-0x500000e01460fd60 ONLINE 0 0 0