Ich habe gerade erst einen Massendatenspeicherpool (ZFS unter Linux 0.6.2, Debian Wheezy) von einer vdev-Konfiguration mit einem einzelnen Gerät auf eine vdev-Konfiguration mit bidirektionaler Spiegelung migriert.
Die vorherige Poolkonfiguration war:
NAME STATE READ WRITE CKSUM
akita ONLINE 0 0 0
ST4000NM0033-Z1Z1A0LQ ONLINE 0 0 0
Nach Abschluss des Resilver-Vorgangs war alles in Ordnung (ich habe nach Abschluss des Resilver-Vorgangs einen Scrub gestartet, nur damit das System alles noch einmal durchgeht und sichergeht, 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, die mich darüber informierte, dass der Pool nicht in Ordnung war. Ich habe nachgeschaut und das hier ist, was ich gesehen habe:
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 Scrub ist zu erwarten; es gibt einen Cron-Job, der beim Neustart ein vollständiges System-Scrub initiiert. Ich habe jedoch definitiv nicht damit gerechnet, dass die neue Festplatte aus dem Spiegel fällt.
Ich definiere Aliase, die den Namen /dev/disk/by-id/wwn-* entsprechen, und habe ZFS bei beiden Datenträgern freie Hand gelassen, den gesamten Datenträger zu verwenden, 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 (mir fällt jetzt auf, dass Z1Z333ZA ein Tabulatorzeichen zur Trennung verwendet, wohingegen die Zeile Z1Z1A0LQ 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 nachschaute, /dev/disk/by-id/wwn-0x5000c50065e8414a*waren sie wie erwartet da, /dev/disk/by-vdev/ST4000NM0033-Z1Z333ZA*waren es aber nicht.
Das Ausgeben sudo udevadm triggerführte dazu, dass die Symlinks in /dev/disk/by-vdev angezeigt wurden. ZFS scheint jedoch nicht zu erkennen, dass sie da sind (Z1Z333ZA wird immer noch als angezeigt UNAVAIL). So viel kann man wohl erwarten.
Ich habe versucht, das entsprechende Gerät auszutauschen, hatte jedoch keinen Erfolg:
# 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'
#
Beim Bootvorgang werden beide Platten erkannt (dmesg-Log-Ausgabe zeigt die entsprechenden 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.
Spontan habe ich Folgendes getan:
# zpool online akita ST4000NM0033-Z1Z333ZA
das scheint funktioniert zu haben; Z1Z333ZA ist jetzt zumindest ONLINEdabei, sich neu zu versilbern. Nach etwa einer Stunde hat es 180 G gescannt und 24 G neu versilbert, wobei 9,77 % abgeschlossen sind, was darauf hindeutet, dass es keine vollständige Neuversilberung durchführt, sondern nur das Datensatzdelta überträgt.
Ich bin ehrlich gesagt nicht sicher, ob dieses Problem mit ZFS unter Linux oder mit udev zusammenhängt (es riecht ein bisschen nach udev, aber warum wird dann ein Laufwerk problemlos erkannt, das andere jedoch nicht), aber meine Frage istwie stelle ich sicher, dass beim nächsten Neustart nicht dasselbe wieder passiert?
Bei Bedarf stelle ich Ihnen gerne weitere Daten zum Setup zur Verfügung. Lassen Sie mich einfach wissen, was benötigt wird.
Antwort1
Dies ist ein udev-Problem, das anscheinendspezifisch für Debian- und Ubuntu-Varianten. Die meiste Arbeit mit ZFS unter Linux mache ich mit CentOS/RHEL.
Dies wurde in ähnlichen Threads in der ZFS-Diskussionsliste erwähnt.
Sehen:
SCSI- und ATA-Einträge für dieselbe Festplatte unter /dev/disk/by-id
Und
ZFS unter Linux/Ubuntu: Hilfe beim Importieren eines Zpools nach dem Ubuntu-Upgrade von 13.04 auf 13.10, Geräte-IDs haben sich geändert
Ich bin mir nicht sicher, was der deterministischste Pool-Geräteansatz für Debian/Ubuntu-Systeme ist. Für RHEL bevorzuge ich die Verwendung von Geräte-WWNs auf allgemeinen Pool-Geräten. Aber manchmal ist auch der Gerätename/die Seriennummer nützlich. Aber udevsollenin der Lage sein, all dies unter Kontrolle 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