Ubuntu aktualisiert, alle Laufwerke in einem Zpool als nicht verfügbar markiert

Ich habe gerade Ubuntu 14.04 aktualisiert und hatte zwei ZFS-Pools auf dem Server. Es gab ein kleines Problem mit dem Kampf mit dem ZFS-Treiber und der Kernel-Version, aber das hat jetzt geklappt. Ein Pool ging online und stieg gut an. Der andere tat es nicht. Der Hauptunterschied zwischen dem Tool besteht darin, dass nur ein Pool von Datenträgern (Video- / Musikspeicher) und der andere ein Raidz-Set (Dokumente usw.) war.

Ich habe bereits versucht, den Pool zu exportieren und erneut zu importieren, ohne Erfolg. Beim Versuch zu importieren erhalte ich Folgendes:

root@kyou:/home/matt# zpool import -fFX -d /dev/disk/by-id/
   pool: storage
     id: 15855792916570596778
  state: UNAVAIL
 status: One or more devices contains corrupted data.
 action: The pool cannot be imported due to damaged devices or data.
   see: http://zfsonlinux.org/msg/ZFS-8000-5E
 config:

        storage                                      UNAVAIL  insufficient replicas
          raidz1-0                                   UNAVAIL  insufficient replicas
            ata-SAMSUNG_HD103SJ_S246J90B134910       UNAVAIL
            ata-WDC_WD10EARS-00Y5B1_WD-WMAV51422523  UNAVAIL
            ata-WDC_WD10EARS-00Y5B1_WD-WMAV51535969  UNAVAIL

Die Symlinks für die in /dev/disk/by-idexistieren auch:

root@kyou:/home/matt# ls -l /dev/disk/by-id/ata-SAMSUNG_HD103SJ_S246J90B134910* /dev/disk/by-id/ata-WDC_WD10EARS-00Y5B1_WD-WMAV51*
lrwxrwxrwx 1 root root  9 May 27 19:31 /dev/disk/by-id/ata-SAMSUNG_HD103SJ_S246J90B134910 -> ../../sdb
lrwxrwxrwx 1 root root 10 May 27 19:15 /dev/disk/by-id/ata-SAMSUNG_HD103SJ_S246J90B134910-part1 -> ../../sdb1
lrwxrwxrwx 1 root root 10 May 27 19:15 /dev/disk/by-id/ata-SAMSUNG_HD103SJ_S246J90B134910-part9 -> ../../sdb9
lrwxrwxrwx 1 root root  9 May 27 19:15 /dev/disk/by-id/ata-WDC_WD10EARS-00Y5B1_WD-WMAV51422523 -> ../../sdd
lrwxrwxrwx 1 root root 10 May 27 19:15 /dev/disk/by-id/ata-WDC_WD10EARS-00Y5B1_WD-WMAV51422523-part1 -> ../../sdd1
lrwxrwxrwx 1 root root 10 May 27 19:15 /dev/disk/by-id/ata-WDC_WD10EARS-00Y5B1_WD-WMAV51422523-part9 -> ../../sdd9
lrwxrwxrwx 1 root root  9 May 27 19:15 /dev/disk/by-id/ata-WDC_WD10EARS-00Y5B1_WD-WMAV51535969 -> ../../sde
lrwxrwxrwx 1 root root 10 May 27 19:15 /dev/disk/by-id/ata-WDC_WD10EARS-00Y5B1_WD-WMAV51535969-part1 -> ../../sde1
lrwxrwxrwx 1 root root 10 May 27 19:15 /dev/disk/by-id/ata-WDC_WD10EARS-00Y5B1_WD-WMAV51535969-part9 -> ../../sde9

Wenn Sie die verschiedenen /dev/sd*aufgelisteten Geräte untersuchen, scheinen sie die richtigen zu sein (die 3 1-TB-Laufwerke, die sich in einem Raidz-Array befanden).

Ich habe zdb -lauf jedem Laufwerk ausgeführt, es in eine Datei geschrieben und ein Diff ausgeführt. Der einzige Unterschied bei den 3 sind die Guid-Felder (von denen ich annehme, dass sie erwartet werden). Alle 3 Etiketten auf jedem sind grundsätzlich identisch und lauten wie folgt:

version: 5000
name: 'storage'
state: 0
txg: 4
pool_guid: 15855792916570596778
hostname: 'kyou'
top_guid: 1683909657511667860
guid: 8815283814047599968
vdev_children: 1
vdev_tree:
    type: 'raidz'
    id: 0
    guid: 1683909657511667860
    nparity: 1
    metaslab_array: 33
    metaslab_shift: 34
    ashift: 9
    asize: 3000569954304
    is_log: 0
    create_txg: 4
    children[0]:
        type: 'disk'
        id: 0
        guid: 8815283814047599968
        path: '/dev/disk/by-id/ata-SAMSUNG_HD103SJ_S246J90B134910-part1'
        whole_disk: 1
        create_txg: 4
    children[1]:
        type: 'disk'
        id: 1
        guid: 18036424618735999728
        path: '/dev/disk/by-id/ata-WDC_WD10EARS-00Y5B1_WD-WMAV51422523-part1'
        whole_disk: 1
        create_txg: 4
    children[2]:
        type: 'disk'
        id: 2
        guid: 10307555127976192266
        path: '/dev/disk/by-id/ata-WDC_WD10EARS-00Y5B1_WD-WMAV51535969-part1'
        whole_disk: 1
        create_txg: 4
features_for_read:

Dummerweise habe ich keine aktuelle Sicherung dieses Pools. Der Pool war jedoch vor dem Neustart in Ordnung, und Linux sieht die Festplatten in Ordnung (ich habe Smartctl jetzt ausgeführt, um es noch einmal zu überprüfen).

Also zusammenfassend:

• Ich habe Ubuntu aktualisiert und den Zugriff auf einen meiner beiden Zpools verloren.
• Der Unterschied zwischen den Pools ist der, der auftauchte, war JBOD, der andere hatte Angst.
• Alle Laufwerke im nicht bereitstellbaren zpool sind mit UNAVAIL gekennzeichnet, ohne Hinweise auf beschädigte Daten
• Die Pools wurden beide mit Datenträgern erstellt, auf die verwiesen wird /dev/disk/by-id/.
• Symlinks von /dev/disk/by-idzu den verschiedenen /dev/sdGeräten scheinen korrekt zu sein
• zdb kann die Etiketten von den Laufwerken lesen.
• Es wurde bereits versucht, den Pool zu exportieren / importieren, und er kann nicht erneut importiert werden.

Gibt es eine Art schwarze Magie, die ich über zpool / zfs aufrufen kann, um diese Festplatten wieder in ein vernünftiges Array zu bringen? Kann ich laufen, zpool create zraid ...ohne meine Daten zu verlieren? Sind meine Daten sowieso weg?

Nach viel, viel mehr Googeln in dieser speziellen Fehlermeldung bekam ich:

root@kyou:/home/matt# zpool import -f storage
cannot import 'storage': one or more devices are already in use

(Hier für Nachwelt- und Suchindizes enthalten) Ich habe Folgendes gefunden:

https://groups.google.com/a/zfsonlinux.org/forum/#!topic/zfs-discuss/VVEwd1VFDmc

Es wurden dieselben Partitionen verwendet und während eines Startvorgangs vor dem Laden von ZFS zu mdraid hinzugefügt.

Ich erinnerte mich, dass ich einige Mdadm-Zeilen gesehen hatte dmesgund zwar:

root@kyou:/home/matt# cat /proc/mdstat
Personalities : [linear] [multipath] [raid0] [raid1] [raid6] [raid5] [raid4] [raid10]
md126 : active raid5 sdd[2] sdb[0] sde[1]
      1953524992 blocks level 5, 64k chunk, algorithm 2 [3/3] [UUU]

Diese Laufwerke waren einst Teil eines Software-Raid5-Arrays. Aus irgendeinem Grund wurde während des Upgrades beschlossen, die Laufwerke erneut zu scannen und festzustellen, dass die Laufwerke einst Teil eines MD-Arrays waren, und es neu zu erstellen. Dies wurde überprüft mit:

root@kyou:/storage# mdadm --examine /dev/sd[a-z]

Diese drei Laufwerke zeigten eine Reihe von Informationen. Vorerst das Array stoppen:

root@kyou:/home/matt# mdadm --stop /dev/md126
mdadm: stopped /dev/md126

Und Import erneut ausführen:

root@kyou:/home/matt# zpool import -f storage

hat das Array wieder online gestellt.

Jetzt mache ich einen Snapshot dieses Pools zur Sicherung und führe mdadm --zero-superblockihn aus.

Ubuntu scheint einige nervige udev-Probleme zu haben , die wir auf der Red Hat / CentOS-Seite nicht sehen. Ich würde empfehlen, die WWN-basierten Gerätenamen zu verwenden, wenn Sie können, da diese weniger anfällig dafür zu sein scheinen.

Haben Sie gesehen: Warum hat ein Neustart dazu geführt, dass eine Seite meines ZFS-Spiegels UNAVAIL wurde?

Ich bin auf fast genau dieses Problem gestoßen, als ich versucht habe, auf die Kernel der 3.13-Serie auf Debian Wheezy zu aktualisieren. Sie haben Recht in Ihrem Kommentar; Es ist ein udev-Fehler. Ich habe es leider nie sortiert bekommen, aber es lohnt sich, andere Kernel, insbesondere die 3.11-Serie, zu untersuchen, um die Kompatibilität mit der 0.6.2-Version von ZOL zu gewährleisten. Verwenden Sie einfach den älteren Kernel, bis 0.6.3 herauskommt.