Raid5 via mdadm: macht Probleme

Piktogramm

Admiral
Registriert
Okt. 2008
Beiträge
9.252
Der Thread dient als Doku und hat Längen. TLDR: Raid5 aus 6 HDDs via mdadm ist kaputt. Es gibt jetzt 2 Gruppen a 3 HDDs mit abweichendem Eventcount, eine HDD ist wahrscheinlich defekt. Mit der Info reicht es wahrscheinlich, den Thread ab jetzt von unten nach oben zu lesen..



Moin,
der Threadtitel wäre besser, würde mir etwas einfallen ;).

Kurz und Knapp main raid5 aus 6 Platten mit BTRFS als Dateisystem ist beim Schreiben einer größeren Datenmenge ausgestiegen und hat den ganzen Rechner mitgerissen. Die Kiste wollte erst wieder booten, als in /etc/fstab nicht mehr versucht wurde das entsprechende Dateisystem einzuhängen.

Code:
> sudo mdadm --detail /dev/md0                                                                
/dev/md0:
        Version : 1.2
     Raid Level : raid0
  Total Devices : 6
    Persistence : Superblock is persistent

          State : inactive

           Name : amd-server:0  (local to host amd-server)
           UUID : 3fe763fa:91cfd832:65bc079b:52e3fbde
         Events : 11575

    Number   Major   Minor   RaidDevice

       -       8       97        -        /dev/sdg1
       -       8       81        -        /dev/sdf1
       -       8       49        -        /dev/sdd1
       -       8       33        -        /dev/sdc1
       -       8       17        -        /dev/sdb1
       -       8        1        -        /dev/sda1

Code:
> cat /proc/mdstat 
Personalities : [linear] [multipath] [raid0] [raid1] [raid6] [raid5] [raid4] [raid10] 
md0 : inactive sdc1[2](S) sdb1[1](S) sdd1[3](S) sdg1[5](S) sdf1[4](S) sda1[0](S)
      17580804096 blocks super 1.2

SMART als Kurzzusammenfassung
Code:
sda -> in Ordnung

sdb ->alte Platte mit hoher Anzahl an Raw Read Error und Seek Errror, die Werte sind stabil und stammen von vor einem Jahr als ein Sata Kabel nicht richtig steckte. (Nach Austausch auf ein besser fixierendes Kabel keine Änderung der Werte). Keine schwebenden / reallokierten Sektoren. Damals waren die HDDs noch nicht als Raid konfiguriert.

sdc->Betriebsstunde 17 von 490 hat hat mehrere Sektoren reallokiert (beim Aufbau des Raids wahrscheinlich), die HDD wird reklamiert. Keine Fehler protokolliert die mit dem Ausfall des Raids korrelieren 

sdd-> in Ordnung

sdf-> siehe sdb

sdg-> in Ordnung

Ich würde das Raid nun gern wieder in Betrieb nehmen, im vollem Bewusstsein, dass ich mindestens eine HDD, besser jedoch 3 kurzfristig tauschen sollte. Das Einhängen von /dev/md0 scheitert selbstverständlich. Zum einen ist das entsprechende Raid "inactive" und zum Anderen sind alle Platten als Spare (das S in Klammern) markiert anstatt als aktive Member. Also hab ich mal geschaut was mdadm mit den vorhandenen Platten anfangen kann:

Code:
sudo mdadm --assemble --scan -v -v
mdadm: looking for devices for /dev/md/0
mdadm: no RAID superblock on /dev/dm-0
mdadm: no RAID superblock on /dev/sdg
mdadm: no RAID superblock on /dev/sdf
mdadm: no RAID superblock on /dev/sde5
mdadm: no RAID superblock on /dev/sde2
mdadm: no RAID superblock on /dev/sde1
mdadm: no RAID superblock on /dev/sde
mdadm: no RAID superblock on /dev/sdd
mdadm: no RAID superblock on /dev/sdc
mdadm: no RAID superblock on /dev/sdb
mdadm: no RAID superblock on /dev/sda
mdadm: /dev/sdg1 is identified as a member of /dev/md/0, slot 5.
mdadm: /dev/sdf1 is identified as a member of /dev/md/0, slot 4.
mdadm: /dev/sdd1 is identified as a member of /dev/md/0, slot 3.
mdadm: /dev/sdc1 is identified as a member of /dev/md/0, slot 2.
mdadm: /dev/sdb1 is identified as a member of /dev/md/0, slot 1.
mdadm: /dev/sda1 is identified as a member of /dev/md/0, slot 0.
mdadm: added /dev/sdb1 to /dev/md/0 as 1 (possibly out of date)
mdadm: added /dev/sdc1 to /dev/md/0 as 2 (possibly out of date)
mdadm: added /dev/sdd1 to /dev/md/0 as 3 (possibly out of date)
mdadm: added /dev/sdf1 to /dev/md/0 as 4
mdadm: added /dev/sdg1 to /dev/md/0 as 5
mdadm: added /dev/sda1 to /dev/md/0 as 0
mdadm: /dev/md/0 assembled from 3 drives - not enough to start the array.

Das ist jetzt nicht so prall und meine Frage ist, wie mache ich aus diesem Zustand wieder ein funktionierendes Raid5 mit möglichst minimalem Datenverlust?

Edit;
cat /proc/mdstat schaut jetzt natürlich so aus:
Code:
cat /proc/mdstat 
Personalities : [linear] [multipath] [raid0] [raid1] [raid6] [raid5] [raid4] [raid10] 
unused devices: <none>

journalctl enthält nur Einträge nach 18.43, was der Zeitpunkt nach dem Ausfall des Raids / Systemabsturzes ist. -.-
 
Zuletzt bearbeitet:
Eine Frage .... erster Codeblock Zeile 4:

Raid Level : raid0

Warum redest du dauernd von Raid5 ??

Hier darf keine einzige Platte ausfallen ....
 
Witzig!
Es ist definitiv ein Raid5 mdstat ist nach dem Fehler aufgetreten und ist anscheinend fehlerhaft.

Auszug vom Log der Installation
Code:
May  8 14:09:01 kernel: [   78.585526] raid6: sse2x1   gen()  2344 MB/s
May  8 14:09:01 kernel: [   78.653529] raid6: sse2x1   xor()  1786 MB/s
May  8 14:09:01 kernel: [   78.721521] raid6: sse2x2   gen()  2765 MB/s
May  8 14:09:01 kernel: [   78.761901] ieee80211 phy0: rt2x00_set_rt: Info - RT chipset 3070, rev 0201 detected
May  8 14:09:01 kernel: [   78.774866] ieee80211 phy0: rt2x00_set_rf: Info - RF chipset 0005 detected
May  8 14:09:01 kernel: [   78.780387] ieee80211 phy0: Selected rate control algorithm 'minstrel_ht'
May  8 14:09:01 kernel: [   78.781029] usbcore: registered new interface driver rt2800usb
May  8 14:09:01 kernel: [   78.783440] rt2800usb 7-1:1.0 wlx801f02e29bba: renamed from wlan0
May  8 14:09:01 kernel: [   78.789527] raid6: sse2x2   xor()  1907 MB/s
May  8 14:09:01 kernel: [   78.857554] raid6: sse2x4   gen()  1681 MB/s
May  8 14:09:01 kernel: [   78.925523] raid6: sse2x4   xor()  2353 MB/s
May  8 14:09:01 kernel: [   78.925525] raid6: using algorithm sse2x2 gen() 2765 MB/s
May  8 14:09:01 kernel: [   78.925526] raid6: .... xor() 1907 MB/s, rmw enabled
May  8 14:09:01 kernel: [   78.925528] raid6: using ssse3x2 recovery algorithm
May  8 14:09:01 kernel: [   78.928190] xor: automatically using best checksumming function: avx
May  8 14:09:01 kernel: [   78.930574] async_tx: api initialized (async)
May  8 14:09:02 kernel: [   78.946303] md: raid6 personality registered for level 6
May  8 14:09:02 kernel: [   78.946306] md: raid5 personality registered for level 5
May  8 14:09:02 kernel: [   78.946307] md: raid4 personality registered for level 4
May  8 14:09:02 kernel: [   78.946735] md/raid:md127: not clean -- starting background reconstruction
May  8 14:09:02 kernel: [   78.946779] md/raid:md127: device sda1 operational as raid disk 0
May  8 14:09:02 kernel: [   78.946782] md/raid:md127: device sdh1 operational as raid disk 5
May  8 14:09:02 kernel: [   78.946784] md/raid:md127: device sdd1 operational as raid disk 2
May  8 14:09:02 kernel: [   78.946786] md/raid:md127: device sdg1 operational as raid disk 4
May  8 14:09:02 kernel: [   78.946788] md/raid:md127: device sde1 operational as raid disk 3
May  8 14:09:02 kernel: [   78.946790] md/raid:md127: device sdc1 operational as raid disk 1
May  8 14:09:02 kernel: [   78.947653] md/raid:md127: allocated 6490kB
May  8 14:09:02 kernel: [   78.947707] md/raid:md127: raid level 5 active with 6 out of 6 devices, algorithm 2
May  8 14:09:02 kernel: [   78.947709] RAID conf printout:
May  8 14:09:02 kernel: [   78.947710]  --- level:5 rd:6 wd:6
May  8 14:09:02 kernel: [   78.947712]  disk 0, o:1, dev:sda1
May  8 14:09:02 kernel: [   78.947714]  disk 1, o:1, dev:sdc1
May  8 14:09:02 kernel: [   78.947716]  disk 2, o:1, dev:sdd1
May  8 14:09:02 kernel: [   78.947717]  disk 3, o:1, dev:sde1
May  8 14:09:02 kernel: [   78.947719]  disk 4, o:1, dev:sdg1
May  8 14:09:02 kernel: [   78.947720]  disk 5, o:1, dev:sdh1
May  8 14:09:02 kernel: [   78.947864] created bitmap (22 pages) for device md127
May  8 14:09:02 kernel: [   78.951862] md127: bitmap initialized from disk: read 2 pages, set 44524 of 44711 bits
May  8 14:09:02 net/hw-detect.hotplug: Detected hotpluggable network interface wlx801f02e29bba
May  8 14:09:02 kernel: [   79.686928] md127: detected capacity change from 0 to 15002286161920

/var/log/journal in Auszügen im Anhang: Anhang anzeigen syslog.txt
Ergänzung ()

OK Syslog sagt, sdc fliegt!

Nachtrag2:
Wobei, syslog sagt, dass die Platte an ata5 Probleme macht. An scsi5 hängt jedoch die Systemplatte (Samsung OEM SSD, nagelneu, lupenreines Smart und fürs Raid nicht weiter relevant)
Ergänzung ()

So weiter geht es mit dem Raid.

Code:
user@dreckskiste:~$ sudo mdadm --examine /dev/sda1 | egrep 'Event|/dev/sd'
/dev/sda1:
         Events : 11575
user@dreckskiste:~$ sudo mdadm --examine /dev/sdb1 | egrep 'Event|/dev/sd'
/dev/sdb1:
         Events : 11570
user@dreckskiste:~$ sudo mdadm --examine /dev/sdc1 | egrep 'Event|/dev/sd'
/dev/sdc1:
         Events : 11570
user@dreckskiste:~$ sudo mdadm --examine /dev/sdd1 | egrep 'Event|/dev/sd'
/dev/sdd1:
         Events : 11570
user@dreckskiste:~$ sudo mdadm --examine /dev/sdf1 | egrep 'Event|/dev/sd'
/dev/sdf1:
         Events : 11575
user@dreckskiste:~$ sudo mdadm --examine /dev/sdg1 | egrep 'Event|/dev/sd'
/dev/sdg1:
         Events : 11575

Wie bereits zu erwarten war, die Platten sind etwas auseinandergelaufen, was bei weiteren Versuchen berücksichtigt werden sollte. Ein Spaß!
Ergänzung ()

Weiter geht es, nicht wundern der Thread ist nebenbei meine Doku :)

Nochmal die Laufwerke anschauen mit
sudo mdadm --examine /dev/sda1
[/CODE]
/dev/sda1:
Magic : a92b4efc
Version : 1.2
Feature Map : 0x1
Array UUID : 3fe763fa:91cfd832:65bc079b:52e3fbde
Name : amd-server:0 (local to host amd-server)
Creation Time : Mon May 8 16:16:02 2017
Raid Level : raid5
Raid Devices : 6

Avail Dev Size : 5860268032 (2794.39 GiB 3000.46 GB)
Array Size : 14650670080 (13971.97 GiB 15002.29 GB)
Data Offset : 262144 sectors
Super Offset : 8 sectors
Unused Space : before=262056 sectors, after=0 sectors
State : clean
Device UUID : b7218f94:0e313d69:aa7f7c4c:3b059ddc

Internal Bitmap : 8 sectors from superblock
Update Time : Wed May 31 18:33:13 2017
Bad Block Log : 512 entries available at offset 72 sectors
Checksum : b80c923f - correct
Events : 11575

Layout : left-symmetric
Chunk Size : 512K

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


/dev/sdb1:
Magic : a92b4efc
Version : 1.2
Feature Map : 0x1
Array UUID : 3fe763fa:91cfd832:65bc079b:52e3fbde
Name : amd-server:0 (local to host amd-server)
Creation Time : Mon May 8 16:16:02 2017
Raid Level : raid5
Raid Devices : 6

Avail Dev Size : 5860268032 (2794.39 GiB 3000.46 GB)
Array Size : 14650670080 (13971.97 GiB 15002.29 GB)
Data Offset : 262144 sectors
Super Offset : 8 sectors
Unused Space : before=262056 sectors, after=0 sectors
State : active
Device UUID : 4434232f:21aa9789:3b43dfd6:25e471c5

Internal Bitmap : 8 sectors from superblock
Update Time : Wed May 31 18:18:38 2017
Bad Block Log : 512 entries available at offset 72 sectors
Checksum : e639bced - correct
Events : 11570

Layout : left-symmetric
Chunk Size : 512K

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


/dev/sdc1:
Magic : a92b4efc
Version : 1.2
Feature Map : 0x1
Array UUID : 3fe763fa:91cfd832:65bc079b:52e3fbde
Name : amd-server:0 (local to host amd-server)
Creation Time : Mon May 8 16:16:02 2017
Raid Level : raid5
Raid Devices : 6

Avail Dev Size : 5860268032 (2794.39 GiB 3000.46 GB)
Array Size : 14650670080 (13971.97 GiB 15002.29 GB)
Data Offset : 262144 sectors
Super Offset : 8 sectors
Unused Space : before=262056 sectors, after=0 sectors
State : active
Device UUID : e4cd1ee5:441d705f:89e4ee33:46a6be32

Internal Bitmap : 8 sectors from superblock
Update Time : Wed May 31 18:18:38 2017
Bad Block Log : 512 entries available at offset 72 sectors
Checksum : 3c6a2f90 - correct
Events : 11570

Layout : left-symmetric
Chunk Size : 512K

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


/dev/sdd1:
Magic : a92b4efc
Version : 1.2
Feature Map : 0x1
Array UUID : 3fe763fa:91cfd832:65bc079b:52e3fbde
Name : amd-server:0 (local to host amd-server)
Creation Time : Mon May 8 16:16:02 2017
Raid Level : raid5
Raid Devices : 6

Avail Dev Size : 5860268032 (2794.39 GiB 3000.46 GB)
Array Size : 14650670080 (13971.97 GiB 15002.29 GB)
Data Offset : 262144 sectors
Super Offset : 8 sectors
Unused Space : before=262056 sectors, after=0 sectors
State : active
Device UUID : c910e416:0a77a089:6ecc863e:01735543

Internal Bitmap : 8 sectors from superblock
Update Time : Wed May 31 18:18:38 2017
Bad Block Log : 512 entries available at offset 72 sectors
Checksum : b38e7e6b - correct
Events : 11570

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 : 3fe763fa:91cfd832:65bc079b:52e3fbde
Name : amd-server:0 (local to host amd-server)
Creation Time : Mon May 8 16:16:02 2017
Raid Level : raid5
Raid Devices : 6

Avail Dev Size : 5860268032 (2794.39 GiB 3000.46 GB)
Array Size : 14650670080 (13971.97 GiB 15002.29 GB)
Data Offset : 262144 sectors
Super Offset : 8 sectors
Unused Space : before=262056 sectors, after=0 sectors
State : clean
Device UUID : bd01b2da:714617e9:4b967ba8:8161da51

Internal Bitmap : 8 sectors from superblock
Update Time : Wed May 31 18:33:13 2017
Bad Block Log : 512 entries available at offset 72 sectors
Checksum : 4f45fa94 - correct
Events : 11575

Layout : left-symmetric
Chunk Size : 512K

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


/dev/sdg1:
Magic : a92b4efc
Version : 1.2
Feature Map : 0x1
Array UUID : 3fe763fa:91cfd832:65bc079b:52e3fbde
Name : amd-server:0 (local to host amd-server)
Creation Time : Mon May 8 16:16:02 2017
Raid Level : raid5
Raid Devices : 6

Avail Dev Size : 5860268032 (2794.39 GiB 3000.46 GB)
Array Size : 14650670080 (13971.97 GiB 15002.29 GB)
Data Offset : 262144 sectors
Super Offset : 8 sectors
Unused Space : before=262056 sectors, after=0 sectors
State : clean
Device UUID : 23a45d9e:5ec819e4:9a8e4de8:5b9e201e

Internal Bitmap : 8 sectors from superblock
Update Time : Wed May 31 18:33:13 2017
Bad Block Log : 512 entries available at offset 72 sectors
Checksum : 1a0c5411 - correct
Events : 11575

Layout : left-symmetric
Chunk Size : 512K

Device Role : Active device 5
Array State : A...AA ('A' == active, '.' == missing, 'R' == replacing)
[/CODE]


Die Platten wissen wenigstens, dass sie im Raid5 waren.

Nächster Schritt wäre jetzt ein Rebuild anzuwerfen mit

mdadm --create --assume-clean --level=5 --raid-devices=6 --size=2930134016 /dev/md0 /dev/sda11 /dev/sdb1 /dev/sdc1 /dev/sdd1 /dev/sdf1 /dev/sgl1

Alternativ um die "böse" /dev/sdc Platte auszusparen sollte auch

mdadm --create --assume-clean --level=5 --raid-devices=6 --size=2930134016 /dev/md0 /dev/sda11 /dev/sdb1 missing /dev/sdd1 /dev/sdf1 /dev/sgl1

gehen. Wobei size=xxx die Hälfte von "Avail Dev Size : 5860268032" ist bzw. Die Größe der Datenträger / Partitionen in Kibibyte (also n * 1024 Byte -.-).

An der Stelle hätte ich gern wirklich Rückmeldung von Jemanden der sich auskennt. Ziel sollte sein, dass /dev/md0 wieder eingehangen werden kann. Das Raid sollte dann zwar als "decraded" markiert sein aber lesen sollte klappen. Geplant wäre dann die wichtigen Daten zu sichern und dann ein Rebuild vom Raid zu starten. Ich hätte da gern mal eine Rückmelung von Jemanden der sich auskennt ob ich da auf dem richtigem Damper bin oder ob ich gerade darauf zusteuere alles noch schlimmer zu machen ;).
 
Zuletzt bearbeitet:
Also ich versuche mal mit meinem Halbwissen zu helfen.
Zur Ursache:
Das der RAID fliegt könnte an den Platten liegen. Ich hatte in meinem RAID5 zwar für 24/7 freigegebene Platten, aber keine die z.B. für einen NAS geeignet waren. Mindestens einmal die Woche hat sich der RAID verabschiedet, weil zwei Platten aus dem Verbund geflogen waren. Nach Umstieg auf WD Red hatte sich das Problem behoben.

Was die Lösung anbetrifft, so werde ich aus Deinem Geschreibsel nicht wirklich schlau.
Versuche doch mal beim assemble die genauen Partitionen anzugeben, anstatt scannen zu lassen. Weiter werde ich nicht ganz schlau draus, wie Du den Rebuild mit der create-Funktion erzwingen willst.
Als mein RAID sich immer verabschiedet hat, habe ich das gemacht, was unter "Controller Fehler" in diesem Wiki steht. Aufgrund der Daten im Superblock startet der Rebuild eigentlich ganz automatisch, wenn der Verbund wieder zusammengesetzt ist.
 
/dev/md0 gibt es schlicht und ergreifend nicht mehr , ich muss es daher irgendwie wieder herstellen. Den Weg den ich dazu bisher gefunden habe läuft leider nur über ein erneutes Erstellen mit den alten Membern. Das es md0 nicht mehr gibt ist dabei verkraftbar, da mdstat das Ding sowieso als raid0 geführt hatte anstatt als raid5.

Was die HDDs angeht, die sind eigentlich sehr sauber entkoppelt und es ist eine einzelne Platte, die sowohl in den Smartwerten als auch im Log durch Ausfälle auffiel. Ich gehe deswegen von einem einzelnem Defekt aus. Vor allem da besagte Platte bereits nach 17h die ersten gravierenden Fehler geworfen hat.
 
So richtig schlauer bin ich jetzt nicht. md0 wird doch vom System vergeben. Wenn da jetzt noch ein anderer RAID läuft, dann isses halt md127 oder md2 oder... Das ist doch voll egal.

Wenn da aber jetzt mehr als 1 Platte aus dem ehemaligen Verbund fehlt, dann isses eh Essig mit dem Rebuild. RAID5 verkraftet nur den Wegfall von einer Platte.
 
Es sind doch alle 6 Platten da, wobei 3 davon einen minimal höheren Eventcount haben (was halbwegs egal sein dürfte).

Es lief nur ein Raid, welches als /dev/md0 angesprochen wurde. Dessen config war aber nachdem Auftreten des Fehlers sowieso für den Allerwertesten. Daher muss ich wenn den Verbund komplett neuaufbauen.
 
Hast du denn das mal versucht, was ich geschrieben habe? Was hat da nicht geklappt?
 
ich baue die alte Config gerade in einer VM nach und werde da dann deinen Tip ausprobieren. Ich bin gestern nicht dazu gekommen mich mit dem Spaß auseinanderzusetzen :/

Da ich mit dem Ausfall des NAS neben den Arbeitskopien nur noch eine Sicherheitskopie habe, muss ich mich auch mal darum kümmern da kurzfristig wieder Sicherheit zu schaffen.
Ergänzung ()

@Win182

DANKE

https://wiki.ubuntuusers.de/Software-RAID/#Controller-Fehler

Hat wirklich gereicht. ich bin das Ganze in der Erwartung angegangen, dass es komplizierter sei -.-
 
Zuletzt bearbeitet:
Zurück
Oben