Perché il riavvio ha fatto diventare UNAVAIL un lato del mio mirror ZFS?


13

Di recente ho migrato un pool di archiviazione di dati di massa (ZFS su Linux 0.6.2, Debian Wheezy) da una configurazione vdev per dispositivo singolo a una configurazione vdev mirror a due vie.

La precedente configurazione del pool era:

    NAME                     STATE     READ WRITE CKSUM
    akita                    ONLINE       0     0     0
      ST4000NM0033-Z1Z1A0LQ  ONLINE       0     0     0

Tutto è andato bene dopo il completamento del resilver (ho avviato uno scrub dopo il completamento del resilver, solo per fare in modo che il sistema ripassasse di nuovo tutto e assicurarmi che fosse tutto a posto):

  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

Tuttavia, dopo il riavvio ho ricevuto un'e-mail che mi informava del fatto che la piscina non andava bene e in modo elegante. Ho dato un'occhiata e questo è quello che ho visto:

   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

Lo scrub è previsto; c'è una configurazione cron job per avviare uno scrub completo del sistema al riavvio. Tuttavia, sicuramente non mi aspettavo che il nuovo HDD cadesse allo specchio.

Definisco gli alias che si associano ai nomi / dev / disk / by-id / wwn- *, e nel caso in cui entrambi questi dischi abbiano dato a ZFS il regno libero di usare l'intero disco, inclusa la gestione del partizionamento:

# 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
# 

Queste sono le righe pertinenti da /etc/zfs/vdev_id.conf (ora noto che Z1Z333ZA utilizza un carattere di tabulazione per la separazione mentre la linea Z1Z1A0LQ utilizza solo spazi, ma onestamente non vedo come ciò possa essere rilevante qui) :

alias ST4000NM0033-Z1Z1A0LQ             /dev/disk/by-id/wwn-0x5000c500645b0fec
alias ST4000NM0033-Z1Z333ZA     /dev/disk/by-id/wwn-0x5000c50065e8414a

Quando ho guardato, /dev/disk/by-id/wwn-0x5000c50065e8414a*c'erano lì come previsto, ma /dev/disk/by-vdev/ST4000NM0033-Z1Z333ZA*non lo erano.

L'emissione ha sudo udevadm triggercausato la visualizzazione dei link simbolici in / dev / disk / by-vdev. Tuttavia, ZFS non sembra solo rendersi conto che ci sono (Z1Z333ZA mostra ancora come UNAVAIL). Suppongo che ci si possa aspettare molto.

Ho provato a sostituire il dispositivo in questione, ma non ho avuto vera fortuna:

# 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'
# 

Entrambi i dischi vengono rilevati durante il processo di avvio (output del registro dmesg che mostra le unità pertinenti):

[    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

Entrambe le unità sono collegate direttamente alla scheda madre; non è previsto alcun controller esterno.

D'impulso, ho fatto:

# zpool online akita ST4000NM0033-Z1Z333ZA

che sembra aver funzionato; Z1Z333ZA è ora almeno ONLINEe resilvering. A circa un'ora dal resilver viene scansionato 180G e resilver 24G con il 9,77% fatto, il che indica che non sta eseguendo un resilver completo ma piuttosto trasferendo solo il delta del set di dati.

Sinceramente non sono sicuro che questo problema sia legato a ZFS su Linux o a udev (ha un odore un po 'di udev, ma allora perché un disco dovrebbe essere rilevato bene ma non l'altro), ma la mia domanda è come faccio sicuro che la stessa cosa non accada di nuovo al prossimo riavvio?

Sarò felice di fornire ulteriori dati sulla configurazione, se necessario; fammi sapere cosa è necessario.

Risposte:


10

Questo è un problema di udev che sembra essere specifico per le varianti di Debian e Ubuntu . Gran parte del mio lavoro su ZFS su Linux è con CentOS / RHEL.

Discussioni simili nell'elenco di discussione ZFS hanno menzionato questo.

Vedi:
voci scsi e ata per lo stesso disco rigido in / dev / disk / by-id
e
ZFS su Linux / Ubuntu: aiuta a importare uno zpool dopo l'aggiornamento di Ubuntu dal 13.04 al 13.10, gli ID dei dispositivi sono cambiati

Non sono sicuro di quale sia l'approccio del dispositivo pool più deterministico per i sistemi Debian / Ubuntu. Per RHEL, preferisco usare i WWN dei dispositivi su dispositivi di pool generali. Altre volte, anche il nome del dispositivo / seriale è utile. Ma udev dovrebbe essere in grado di tenere tutto sotto controllo.

# 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

1
Dopo la migrazione a wwn-*nomi semplici , il pool sembra essere stabile.
un CVn

1
@ MichaelKjörling puoi descrivere in dettaglio come sei passato ai nomi di wwn- *?
codecowboy,

1
@codecowboy Niente di speciale. zpool detach akita ST4000NM0033-Z1Z333ZApoi zpool attach -o ashift=12 -f akita ST4000NM0033-Z1Z1A0LQ wwn-0x5000c50065e8414apoi zpool detach akita ST4000NM0033-Z1Z1A0LQpoi zpool attach akita wwn-0x5000c50065e8414a wwn-0x5000c500645b0fec, verificando tra un passo che la piscina era stabile. Consiglio vivamente prima uno scrub accurato. Probabilmente potresti anche zpool replacefarcela, ma dal momento che gli alias indicavano i nomi dei wwn e che avevo ridondanza e backup, mi sembrava più sicuro. Ci sono voluti alcuni giorni ma non avevo fretta.
un CVn
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.