Recientemente migré un grupo de almacenamiento de datos masivos (ZFS en Linux 0.6.2, Debian Wheezy) de una configuración vdev de un solo dispositivo a una configuración vdev de espejo bidireccional.
La configuración anterior del grupo era:
NAME STATE READ WRITE CKSUM
akita ONLINE 0 0 0
ST4000NM0033-Z1Z1A0LQ ONLINE 0 0 0
Todo estuvo bien después de que se completó el resilver (inicié una limpieza después de que se completó el resilver, solo para que el sistema revisara todo una vez más y se asegurara de que todo estuviera 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
Sin embargo, después de reiniciar recibí un correo electrónico notificándome que el grupo no estaba bien. Eché un vistazo y esto es lo 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
Se espera el matorral; hay una configuración de trabajo cron para iniciar una limpieza completa del sistema al reiniciar. Sin embargo, definitivamente no esperaba que el nuevo disco duro se cayera del espejo.
Defino alias que se asignan a los nombres /dev/disk/by-id/wwn-* y, en el caso de ambos discos, le he dado rienda suelta a ZFS para usar el disco completo, incluido el manejo de particiones:
# 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 son las líneas relevantes de /etc/zfs/vdev_id.conf (ahora me doy cuenta de que Z1Z333ZA usa un carácter de tabulación para la separación, mientras que la línea Z1Z1A0LQ usa solo espacios, pero honestamente no veo cómo eso podría ser relevante aquí) :
alias ST4000NM0033-Z1Z1A0LQ /dev/disk/by-id/wwn-0x5000c500645b0fec
alias ST4000NM0033-Z1Z333ZA /dev/disk/by-id/wwn-0x5000c50065e8414a
Cuando miré, /dev/disk/by-id/wwn-0x5000c50065e8414a*estaban allí como esperaba, pero /dev/disk/by-vdev/ST4000NM0033-Z1Z333ZA*no estaban.
La emisión sudo udevadm triggerprovocó que los enlaces simbólicos aparecieran en /dev/disk/by-vdev. Sin embargo, ZFS no parece darse cuenta de que están allí (Z1Z333ZA todavía se muestra como UNAVAIL). Supongo que eso es lo que se puede esperar.
Intenté reemplazar el dispositivo correspondiente, pero no tuve mucha suerte:
# 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 discos se detectan durante el proceso de arranque (la salida del registro dmesg muestra las 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 unidades están conectadas directamente a la placa base; no hay ningún controlador externo involucrado.
Por impulso, hice:
# zpool online akita ST4000NM0033-Z1Z333ZA
que parece haber funcionado; Z1Z333ZA ahora al menos está ONLINEreplateado. Aproximadamente una hora después del resilver, se escaneó 180G y se resilverizó 24G con un 9,77 % completado, lo que indica que no está realizando un resilver completo sino que solo transfirió el delta del conjunto de datos.
Sinceramente, no estoy seguro de si este problema está relacionado con ZFS en Linux o con udev (huele un poco a udev, pero entonces ¿por qué se detectaría bien una unidad pero no la otra), pero mi pregunta es¿Cómo me aseguro de que no vuelva a suceder lo mismo en el próximo reinicio?
Estaré encantado de proporcionar más datos sobre la configuración si es necesario; sólo déjame saber lo que se necesita.
Respuesta1
Este es un problema de udev que parece serespecífico para las variantes de Debian y Ubuntu. La mayor parte de mi trabajo con ZFS en Linux es con CentOS/RHEL.
Hilos similares en la lista de discusión de ZFS han mencionado esto.
Ver:
Entradas scsi y ata para el mismo disco duro en /dev/disk/by-id
y
ZFS en Linux/Ubuntu: Ayuda para importar un zpool después de la actualización de Ubuntu de 13.04 a 13.10, las ID de los dispositivos han cambiado
No estoy seguro de cuál es el enfoque de dispositivo de grupo más determinista para los sistemas Debian/Ubuntu. Para RHEL, prefiero usar WWN de dispositivo en dispositivos de grupo general. Pero otras veces, el nombre/serie del dispositivo también es útil. pero udevdeberíapoder mantener todo esto bajo control.
# 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