¿Por qué el reinicio hizo que un lado de mi espejo ZFS se convirtiera en UNAVAIL?

13

Recientemente migré un grupo de almacenamiento de datos masivo (ZFS en Linux 0.6.2, Debian Wheezy) de una configuración vdev de un solo dispositivo a una configuración vdev espejo de dos vías.

La configuración del grupo anterior 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 programa de recuperación (inicié un exfoliante después de que se completó el programa de recuperación, solo para que el sistema repase todo una vez más y me asegure de que todo esté 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 el hecho de que el grupo no estaba bien y elegante. 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 exfoliante; hay una configuración de trabajo cron para iniciar una limpieza completa del sistema al reiniciar. Sin embargo, definitivamente no esperaba que el nuevo HDD se cayera del espejo.

Defino alias que se asignan a los nombres / dev / disk / by-id / wwn- *, y en caso de que ambos discos hayan dado a ZFS un reinado libre para usar el disco completo, incluido el manejo de la partición:

# 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 se 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). Eso supongo que se puede esperar.

Intenté reemplazar el dispositivo relevante, pero no tuve suerte real:

# 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 un controlador externo involucrado.

Por impulso, hice:

# zpool online akita ST4000NM0033-Z1Z333ZA

que parece haber funcionado; Z1Z333ZA ahora es al menos ONLINEy resistente. Aproximadamente una hora en el resilver se escanea 180G y se reagrupa 24G con un 9.77%, lo que indica que no realiza un resilenciador completo sino que solo transfiere el conjunto de datos delta.

Honestamente, 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é una unidad se detectaría bien pero no la otra?), Pero mi pregunta es cómo hago ¿Seguro que no volverá a ocurrir lo mismo en el próximo reinicio?

Estaré encantado de proporcionar más datos sobre la configuración si es necesario; solo házmelo saber lo que se necesita.

un CVn
fuente

Respuestas:

10

Este es un problema de udev que parece ser específico para las variantes de Debian y Ubuntu . La mayor parte de mi trabajo de 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 udev debería poder 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
ewwhite
fuente
1
Después de migrar a wwn-*nombres desnudos , el grupo parece ser estable.
un CVn
1
@ MichaelKjörling, ¿puede detallar cómo migró a wwn- * names?
codecowboy
1
@codecowboy Nada lujoso en absoluto. zpool detach akita ST4000NM0033-Z1Z333ZAluego zpool attach -o ashift=12 -f akita ST4000NM0033-Z1Z1A0LQ wwn-0x5000c50065e8414a, zpool detach akita ST4000NM0033-Z1Z1A0LQluego zpool attach akita wwn-0x5000c50065e8414a wwn-0x5000c500645b0fec, verificando entre cada paso que el grupo era estable. Recomiendo un exfoliante completo primero. Probablemente también podría salirse con la suya zpool replace, pero como los alias apuntaban a los nombres wwn y tenía redundancia más copias de seguridad, esto se sintió más seguro. Tomó unos días pero no tenía prisa.
un CVn