☰

MD Raid6-Array verschwand beim Neustart

tag-icon • tag-icon ubuntu mdadm raid6
MD Raid6-Array verschwand beim Neustart

mein RAID6-Array verschwand beim Neustart, nachdem ich es vergrößert hatte. Ich glaube, das Problem war, dass es mit der vollen Festplatte, nicht mit der Partition, doppelt so groß wurde. Es wurde ein möglicher anderer Grund dafür genannt, dass die Laufwerke nicht richtig erkannt wurden: Ich habe die Superblöcke nicht auf Null gesetzt, bevor ich sie erneut zu einem neuen Array hinzugefügt habe. Könnte es eine Kombination aus beidem sein? Hier sind die ausgegebenen Befehle (aus dem Verlauf gezogen, formatiert, um konsistente Laufwerksbuchstaben zu haben):

mdadm --create --verbose /dev/md0 --level=0 --raid-devices=2 /dev/sd[b-c]1

#Vollständige Sicherung von ROC RAID 10 auf diesen Laufwerken. Nachdem Sie die meisten Dateien auf andere Laufwerke kopiert haben, überprüfen Sie, ob der Neustart funktioniert hat.

mdadm --create /dev/md1 --level=6 --raid-devices=4 /dev/sd[d-g]1

#Zeit zum Synchronisieren der Laufwerke und anschließendes Rsyncen der Daten von md0 verstrichen, Neustart einwandfrei.

mdadm -S /dev/md0
mdadm /dev/md0 -r /dev/sd[b-c]

#BEACHTEN SIE DIE FEHLENDE PARTITIONSNUMMER UNTEN.

mdadm /dev/md1 --add /dev/sdb
mdadm /dev/md1 --add /dev/sdc
mdadm -list
mdadm --detail /dev/md1
mdadm --grow --raid-devices=6 --backup-file=/media/FastRaid/md1_grow.bak /dev/md1

Nach einem Neustart ist das Raid6 verschwunden und durch zwei Raid0-Arrays ersetzt, eines aktiv (sdb/sdc) und eines inaktiv (sdd-sdg). Das Folgende erhalte ich aus der Untersuchung der Superblöcke:

/dev/sdb1:
        Magic : a92b4efc
        Version : 1.2
    Feature Map : 0x0
    Array UUID : 501c08da:5069a3d8:b2982a5d:ab56c37c
        Name : tim-server:0  (local to host tim-server)
Creation Time : Tue Dec 13 22:01:10 2022
    Raid Level : raid0
Raid Devices : 2

Avail Dev Size : 7813770895 (3725.90 GiB 4000.65 GB)
    Data Offset : 264192 sectors
Super Offset : 8 sectors
Unused Space : before=264112 sectors, after=0 sectors
        State : clean
    Device UUID : e8db27d6:0dbd1ac5:4456c304:0b43f09c

    Update Time : Tue Dec 13 22:01:10 2022
Bad Block Log : 512 entries available at offset 8 sectors
    Checksum : dfd187c0 - correct
        Events : 0

    Chunk Size : 512K

Device Role : Active device 0
Array State : AA ('A' == active, '.' == missing, 'R' == replacing)
/dev/sdc1:
        Magic : a92b4efc
        Version : 1.2
    Feature Map : 0x0
    Array UUID : 501c08da:5069a3d8:b2982a5d:ab56c37c
        Name : tim-server:0  (local to host tim-server)
Creation Time : Tue Dec 13 22:01:10 2022
    Raid Level : raid0
Raid Devices : 2

Avail Dev Size : 7813770895 (3725.90 GiB 4000.65 GB)
    Data Offset : 264192 sectors
Super Offset : 8 sectors
Unused Space : before=264112 sectors, after=0 sectors
        State : clean
    Device UUID : 3ce84b05:607f8565:456e7f83:88b83052

    Update Time : Tue Dec 13 22:01:10 2022
Bad Block Log : 512 entries available at offset 8 sectors
    Checksum : e35ce3e5 - correct
        Events : 0

    Chunk Size : 512K

Device Role : Active device 1
Array State : AA ('A' == active, '.' == missing, 'R' == replacing)
/dev/sdd1:
        Magic : a92b4efc
        Version : 1.2
    Feature Map : 0x1
    Array UUID : 929a14c9:adaf502a:53658e03:90a19fce
        Name : tim-server:0  (local to host tim-server)
Creation Time : Wed Dec 14 11:18:57 2022
    Raid Level : raid6
Raid Devices : 6

Avail Dev Size : 7813770895 (3725.90 GiB 4000.65 GB)
    Array Size : 15627540480 (14903.58 GiB 16002.60 GB)
Used Dev Size : 7813770240 (3725.90 GiB 4000.65 GB)
    Data Offset : 264192 sectors
Super Offset : 8 sectors
Unused Space : before=264112 sectors, after=655 sectors
        State : clean
    Device UUID : eaf10189:940aeaf8:947efe82:5d0e4aea

Internal Bitmap : 8 sectors from superblock
    Update Time : Sun Dec 18 06:31:11 2022
Bad Block Log : 512 entries available at offset 24 sectors
    Checksum : e38a1bd9 - correct
        Events : 26630

        Layout : left-symmetric
    Chunk Size : 512K

Device Role : Active device 1
Array State : AAAAAA ('A' == active, '.' == missing, 'R' == replacing)
/dev/sde1:
        Magic : a92b4efc
        Version : 1.2
    Feature Map : 0x1
    Array UUID : 929a14c9:adaf502a:53658e03:90a19fce
        Name : tim-server:0  (local to host tim-server)
Creation Time : Wed Dec 14 11:18:57 2022
    Raid Level : raid6
Raid Devices : 6

Avail Dev Size : 7813770895 (3725.90 GiB 4000.65 GB)
    Array Size : 15627540480 (14903.58 GiB 16002.60 GB)
Used Dev Size : 7813770240 (3725.90 GiB 4000.65 GB)
    Data Offset : 264192 sectors
Super Offset : 8 sectors
Unused Space : before=264112 sectors, after=655 sectors
        State : clean
    Device UUID : 5c34a9c7:bcc3f190:d1719a9c:8aa2b722

Internal Bitmap : 8 sectors from superblock
    Update Time : Sun Dec 18 06:31:11 2022
Bad Block Log : 512 entries available at offset 24 sectors
    Checksum : c429edf - correct
        Events : 26630

        Layout : left-symmetric
    Chunk Size : 512K

Device Role : Active device 3
Array State : AAAAAA ('A' == active, '.' == missing, 'R' == replacing)
/dev/sdf1:
        Magic : a92b4efc
        Version : 1.2
    Feature Map : 0x1
    Array UUID : 929a14c9:adaf502a:53658e03:90a19fce
        Name : tim-server:0  (local to host tim-server)
Creation Time : Wed Dec 14 11:18:57 2022
    Raid Level : raid6
Raid Devices : 6

Avail Dev Size : 7813770895 (3725.90 GiB 4000.65 GB)
    Array Size : 15627540480 (14903.58 GiB 16002.60 GB)
Used Dev Size : 7813770240 (3725.90 GiB 4000.65 GB)
    Data Offset : 264192 sectors
Super Offset : 8 sectors
Unused Space : before=264112 sectors, after=655 sectors
        State : clean
    Device UUID : 12d1e3a8:b8749f59:654bcca4:4f4750df

Internal Bitmap : 8 sectors from superblock
    Update Time : Sun Dec 18 06:31:11 2022
Bad Block Log : 512 entries available at offset 24 sectors
    Checksum : 7af56ae7 - correct
        Events : 26630

        Layout : left-symmetric
    Chunk Size : 512K

Device Role : Active device 0
Array State : AAAAAA ('A' == active, '.' == missing, 'R' == replacing)
/dev/sdg1:
        Magic : a92b4efc
        Version : 1.2
    Feature Map : 0x1
    Array UUID : 929a14c9:adaf502a:53658e03:90a19fce
        Name : tim-server:0  (local to host tim-server)
Creation Time : Wed Dec 14 11:18:57 2022
    Raid Level : raid6
Raid Devices : 6

Avail Dev Size : 7813770895 (3725.90 GiB 4000.65 GB)
    Array Size : 15627540480 (14903.58 GiB 16002.60 GB)
Used Dev Size : 7813770240 (3725.90 GiB 4000.65 GB)
    Data Offset : 264192 sectors
Super Offset : 8 sectors
Unused Space : before=264112 sectors, after=655 sectors
        State : clean
    Device UUID : 72085967:835efe92:cb268a64:4d192b52

Internal Bitmap : 8 sectors from superblock
    Update Time : Sun Dec 18 06:31:11 2022
Bad Block Log : 512 entries available at offset 24 sectors
    Checksum : a5623977 - correct
        Events : 26630

        Layout : left-symmetric
    Chunk Size : 512K

Device Role : Active device 2
Array State : AAAAAA ('A' == active, '.' == missing, 'R' == replacing)

Ich hatte md0 irgendwann deaktiviert, also habe ich es mit neu erstellt mdadm -A -o /dev/md0 /dev/sdb1 /dev/sdc1. Das ist /proc/mdstatjetzt:

cat /proc/mdstat

Personalities : [raid0] [linear] [multipath] [raid1] [raid6] [raid5] [raid4] [raid10]
md0 : active (read-only) raid0 sdb1[0] sdc1[1]
  7813770240 blocks super 1.2 512k chunks

md1 : inactive sdf1[0](S) sde1[3](S) sdd1[1](S) sdg1[2](S)
    15627541790 blocks super 1.2

unused devices: <none>

Wenn ich es versuche, mount /dev/md0 /media/tmp_md_raiderhalte ich: mount: /media/tmp_md_raid: wrong fs type, bad option, bad superblock on /dev/md126, missing codepage or helper program, or other error.. Wenn ich es versuche: mdadm -A -o /dev/md1 /dev/sdf1 /dev/sde1 /dev/sdd1 /dev/sdg1erhalte ich:

mdadm: /dev/sdf1 is busy - skipping
mdadm: /dev/sde1 is busy - skipping
mdadm: /dev/sdd1 is busy - skipping
mdadm: /dev/sdg1 is busy - skipping

Alle Smartctls sagen, dass alle Laufwerke in Ordnung sind. Ich bin mir nicht sicher, ob ich zuerst mdadm --assemble --force oder mdadm --create --assume-clean ausprobieren soll. Soll ich das zweite mit -o versuchen, um zu sehen, ob ich das Array neu erstellen und die Daten anzeigen kann, ohne möglicherweise die Wiederherstellung zu zerstören? Danke für jeden Rat.

Antwort1

Es scheint, dass Sie ein Array mit 6 Geräten haben (AAAAAA), aber nur 4 Komponentengeräte sind verfügbar ( /dev/sd[defg]1). Die Kapazitätsberechnung bestätigt dies: Man benötigt 6 Festplatten mit 4 TB, um ein 16 TB RAID6-Array zu erstellen.

Da es sich um RAID6 handelt und alle 4 verfügbaren Geräte synchron zu sein scheinen, kann es ausgeführt werden, allerdings nur in sog.vollständig abgebautModus. In diesem Modus muss zum Lesen eines Blocks ein Streifen von allen Laufwerken gelesen werden (was E/A-intensiv ist) und eine Rekonstruktion durchgeführt werden (es werden sowohl Paritätssyndrome verwendet, was CPU-intensive Galois-Feldberechnungen beinhaltet), und zum Schreiben eines Blocks muss der gesamte Streifen gelesen, neue Paritätssyndrome berechnet und auf mindestens drei Geräte geschrieben werden (was insgesamt noch E/A-intensiver ist).

Linux hat keine andere Wahl, als darauf zurückzugreifen, wenn das Array ausgeführt wurde und ein Gerät während der Verwendung ausfällt. Das ist der Sinn eines RAID-Arrays. Wie Sie vielleicht schon vermutet haben, ist die Leistung in diesem Zustand sehr schlecht und das Risiko eines Datenverlusts sehr hoch. Deshalb sollten Sie ein Array nicht über längere Zeit in diesem Zustand ausführen. Idealerweise stellen Sie zusätzlich zu den funktionierenden Geräten ein Hotspare bereit, damit sofort mit der Wiederherstellung begonnen werden kann, wenn der Ausfall einer Komponente erkannt wird.

Beim Booten weiß es jedoch nicht, ob einige Geräte dauerhaft fehlen oder ob sie aufgrund von gestaffeltem Hochfahren oder anderen Initialisierungsverzögerungen einfach noch nicht verfügbar sind. Eine frühzeitige Aktivierung des Arrays führt dazu, dass verspätete Geräte nicht mehr synchron sind und eine zeitintensive Neusynchronisierung erzwungen wird, bei der das Array die schlechteste Leistungscharakteristik aufweist, wie oben beschrieben. Dies motiviert dazu, auf verspätet erscheinende Geräte zu warten. Linux aktiviert teilweise verfügbare Arrays standardmäßig nicht automatisch, selbst wenn genügend Geräte vorhanden sind, um es zumindest in einem eingeschränkten Modus auszuführen.

Aber Sie als Administrator könnenGewaltes zu tun. DafürBauen Sie das Array wieder zusammen mit--force:

mdadm --stop /dev/md1
mdadm --force --assemble /dev/md1 /dev/sd[defg]1

Genauer gesagt wird das Array nicht automatisch zusammengesetzt, wenn weniger Geräte verfügbar sind, als in den Superblöcken der vorhandenen Geräte aufgezeichnet sind (in Ihrem Fall wird aufgezeichnet, dass beim letzten Mal alle Geräte verfügbar waren); wenn Sie ein Gerät ordnungsgemäß mit der Sequenz mdadm -f/ entfernen mdadm -roder es zwangsweise zusammensetzen, wird dies aufgezeichnet und das Array wird dann automatisch zusammengesetzt inDasselbeDer degradierte Zustand wird automatisch wiederhergestellt.

Wenn dieses Array keine wertvollen Daten enthält, erstellen Sie es besser neu. Die Initialisierung fühlt sichSchnellerals Geräte hinzuzufügen und den Wiederaufbau zu erleiden.

verwandte Informationen