Warum hat ein Neustart dazu geführt, dass eine Seite meines ZFS-Spiegels NICHT VERFÜGBAR war?

13

Ich habe kürzlich einen Massendatenspeicherpool (ZFS On Linux 0.6.2, Debian Wheezy) von einer vdev-Konfiguration mit einem Gerät auf eine vdev-Konfiguration mit zwei Spiegeln migriert.

Die vorherige Poolkonfiguration war:

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

Nach Abschluss des Resilvers war alles in Ordnung (ich habe nach Abschluss des Resilvers ein Peeling eingeleitet, damit das System alles noch einmal durchgeht und sicherstellt, dass alles in Ordnung ist):

  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

Nach dem Neustart erhielt ich jedoch eine E-Mail, in der ich darüber informiert wurde, dass der Pool nicht in Ordnung und ordentlich war. Ich habe nachgesehen und das habe ich gesehen:

   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

Das Peeling wird erwartet; Es gibt ein Cron-Job-Setup, um beim Neustart ein vollständiges System-Scrub zu initiieren. Allerdings hatte ich definitiv nicht damit gerechnet, dass die neue Festplatte aus dem Spiegel fällt.

Ich definiere Aliase, die den Namen / dev / disk / by-id / wwn- * zugeordnet sind, und in beiden Fällen hat ZFS freie Hand, um die gesamte Festplatte zu nutzen, einschließlich der Partitionierung:

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

Dies sind die relevanten Zeilen aus /etc/zfs/vdev_id.conf (Ich bemerke jetzt, dass der Z1Z333ZA ein Tabulatorzeichen zur Trennung verwendet, während die Z1Z1A0LQ-Zeile nur Leerzeichen verwendet, aber ich sehe ehrlich gesagt nicht, wie das hier relevant sein könnte.) :

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

Als ich hinsah, /dev/disk/by-id/wwn-0x5000c50065e8414a*waren da wie erwartet, waren es aber /dev/disk/by-vdev/ST4000NM0033-Z1Z333ZA*nicht.

Das Problem führte dazu, sudo udevadm triggerdass die Symlinks in / dev / disk / by-vdev angezeigt wurden. ZFS scheint jedoch nicht nur zu bemerken, dass sie da sind (Z1Z333ZA wird immer noch als angezeigt UNAVAIL). Soviel kann ich wohl erwarten.

Ich habe versucht, das entsprechende Gerät auszutauschen, hatte aber kein wirkliches Glück:

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

Beide Festplatten werden während des Startvorgangs erkannt (dmesg-Protokollausgabe mit Angabe der relevanten Laufwerke):

[    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

Beide Laufwerke sind direkt mit der Hauptplatine verbunden. Es ist kein externer Controller beteiligt.

Aus einem Impuls heraus tat ich:

# zpool online akita ST4000NM0033-Z1Z333ZA

was anscheinend funktioniert hat; Z1Z333ZA ist jetzt mindestens ONLINEund resilvering. Nach ungefähr einer Stunde ist der Resilver mit 180G gescannt und 24G mit 9,77% resilbert, was darauf hindeutet, dass kein vollständiges Resilver durchgeführt wird, sondern nur das Delta des Datensatzes übertragen wird.

Ich bin mir ehrlich gesagt nicht sicher, ob dieses Problem mit ZFS unter Linux oder mit udev zusammenhängt (es riecht ein bisschen nach udev, aber warum würde dann ein Laufwerk nur in Ordnung erkannt, aber nicht das andere), aber meine Frage ist, wie mache ich das? sicher, dass dasselbe beim nächsten Neustart nicht noch einmal passiert?

Gerne stelle ich Ihnen weitere Daten zum Setup zur Verfügung. Lass mich wissen, was gebraucht wird.

ein CVn
quelle

Antworten:

10

Dies ist ein udev-Problem, das spezifisch für Debian- und Ubuntu-Varianten zu sein scheint . Der Großteil meiner Arbeit mit ZFS unter Linux läuft unter CentOS / RHEL.

Ähnliche Themen auf der ZFS-Diskussionsliste haben dies erwähnt.

Siehe:
scsi- und ata-Einträge für dieselbe Festplatte unter / dev / disk / by-id
und
ZFS unter Linux / Ubuntu: Helfen Sie beim Importieren eines Zpools nach dem Ubuntu-Upgrade von 13.04 auf 13.10. Die Geräte-IDs haben sich geändert

Ich bin mir nicht sicher, was der deterministischste Ansatz für Pool-Geräte für Debian / Ubuntu-Systeme ist. Für RHEL bevorzuge ich die Verwendung von Geräte-WWNs auf allgemeinen Poolgeräten. Aber manchmal ist auch der Gerätename / die Seriennummer nützlich. Aber udev sollte in der Lage sein, all dies in Schach zu halten.

# 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
quelle
1
Nach der Migration zu unbeschriebenen wwn-*Namen scheint der Pool stabil zu sein.
ein Lebenslauf
1
@ MichaelKjörling kannst du genau beschreiben, wie du zu wwn- * names migriert bist?
Codecowboy
1
@codecowboy Gar nichts Besonderes. zpool detach akita ST4000NM0033-Z1Z333ZAdann zpool attach -o ashift=12 -f akita ST4000NM0033-Z1Z1A0LQ wwn-0x5000c50065e8414adann zpool detach akita ST4000NM0033-Z1Z1A0LQdann zpool attach akita wwn-0x5000c50065e8414a wwn-0x5000c500645b0fec, zwischen jedem Schritt überprüfend, dass der Pool beständig war. Ich empfehle zuerst ein gründliches Peeling. Sie könnten wahrscheinlich auch davonkommen, zpool replaceaber da die Aliase auf die wwn-Namen zeigten und ich Redundanz plus Backups hatte, fühlte sich das sicherer an. Dauerte ein paar Tage, aber ich war nicht in Eile.
ein Lebenslauf