XFS kann den Superblock nicht lesen

XFS kann den Superblock nicht lesen

Als ich heute Morgen aufwachte, fand ich eine E-Mail von meinem RAID-Host (Linux-Software-RAID), in der mir mitgeteilt wurde, dass ein Laufwerk ausgefallen sei. Es handelt sich um Consumer-Hardware, also keine große Sache. Ich habe kalte Ersatzteile. Als ich jedoch zum Server kam, reagierte das ganze Ding nicht mehr. Irgendwann dachte ich, ich hätte keine andere Wahl, als den Strom abzuschalten und neu zu starten.

Das System ist hochgefahren, das ausgefallene Laufwerk ist immer noch als ausgefallen markiert und /proc/mdstatsieht korrekt aus. Es lässt sich jedoch nicht mounten /dev/md0und sagt mir:

mount: /dev/md0: can't read superblock

Jetzt mache ich mir langsam Sorgen. Also versuche ich es mit xfs_checkund xfs_repair, wobei ersteres mir sagt:

xfs_check: /dev/md0 is invalid (cannot read first 512 bytes)

und letzteres:

Phase 1 - find and verify superblock...
superblock read failed, offset 0, size 524288, ag 0, rval 0

fatal error -- Invalid argument

Jetzt bekomme ich langsam Angst. Bisher hat mein Googeln nichts gebracht. Ich bin jetzt noch nicht in Panik, weil ich schon früher Angst hatte und es immer innerhalb weniger Tage geklappt hat. Ich kann heute Abend immer noch mein kaltes Ersatzlaufwerk einlegen, es neu aufbauen lassen (für 36 Stunden) und dann sehen, ob das Dateisystem in einem besser nutzbaren Zustand ist. Ich kann vielleicht sogar versuchen, das Array von den aktuellen 11 Laufwerken wieder auf 10 zu reduzieren (da ich das Dateisystem noch nicht erweitert habe) und sehen, ob das hilft (was fast eine Woche dauern würde).

Aber bevor ich irgendetwas davon heute Abend zu Hause erledigen kann, möchte ich, während ich auf der Arbeit bin, die Hilfe der hier anwesenden Experten in Anspruch nehmen.

Hat jemand, der sich mit Dateisystemen und RAID besser auskennt, Empfehlungen? Vielleicht kann ich von hier aus über SSH etwas tun, um das Dateisystemproblem genauer zu diagnostizieren oder es vielleicht sogar zu reparieren?

Bearbeiten:

Sieht so aus, als ob /proc/mdstates tatsächlich einen Hinweis bietet:

Personalities : [linear] [raid0] [raid1] [raid10] [raid6] [raid5] [raid4] [multipath]
md0 : inactive sdk1[10] sdh1[7] sdj1[5] sdg1[8] sdi1[6] sdc1[2] sdd1[3] sde1[4] sdf1[9] sdb1[0]
      19535119360 blocks

inactive? Also versuche ich das Array zusammenzustellen:

# mdadm --assemble /dev/md0 /dev/sdb1 /dev/sdc1 /dev/sdd1 /dev/sde1 /dev/sdf1 /dev/sdg1 /dev/sdh1 /dev/sdi1 /dev/sdj1 /dev/sdk1
mdadm: device /dev/md0 already active - cannot assemble it

Es ist bereits aktiv? Obwohl /proc/mdstatmir angezeigt wird, dass es inaktiv ist?

Antwort1

Es stellte sich heraus, dass der potenzielle Datenverlust nicht so schlimm war, wie ich zu befürchten begann. Als ich bemerkte, dass das Array zwar zusammengestellt wurde, inactiveaber nicht zusammengestellt werden konnte, stoppte ich es:

# mdadm -S /dev/md0
mdadm: stopped /dev/md0

Dannhabe versucht es zusammenzubauen:

# mdadm --assemble /dev/md0 /dev/sdb1 /dev/sdc1 /dev/sdd1 /dev/sde1 /dev/sdf1 /dev/sdg1 /dev/sdh1 /dev/sdi1 /dev/sdj1 /dev/sdk1
mdadm: /dev/md0 assembled from 10 drives - not enough to start the array while not clean - consider --force.

Immer noch ein bisschen gruselig, mal sehen, was es /proc/mdstatzu sagen hat:

# cat /proc/mdstat
Personalities : [linear] [raid0] [raid1] [raid10] [raid6] [raid5] [raid4] [multipath]
md0 : inactive sdb1[0](S) sdk1[10](S) sdf1[9](S) sdg1[8](S) sdh1[7](S) sdi1[6](S) sdj1[5](S) sde1[4](S) sdd1[3](S) sdc1[2](S)
      19535119360 blocks

Alles... Ersatzteile...? Ok, wieder Angst. Stopp es noch mal:

# mdadm -S /dev/md0
mdadm: stopped /dev/md0

Und probieren Sie die Vorschläge aus, indem Sie Folgendes verwenden --force:

# mdadm --assemble /dev/md0 /dev/sdb1 /dev/sdc1 /dev/sdd1 /dev/sde1 /dev/sdf1 /dev/sdg1 /dev/sdh1 /dev/sdi1 /dev/sdj1 /dev/sdk1 --force
mdadm: /dev/md0 has been started with 10 drives (out of 11).

10 von 11, da einer im Regal neben dem Computer steht, soweit so gut:

# cat /proc/mdstat
Personalities : [linear] [raid0] [raid1] [raid10] [raid6] [raid5] [raid4] [multipath]
md0 : active raid6 sdb1[0] sdk1[10] sdf1[9] sdg1[8] sdh1[7] sdi1[6] sdj1[5] sde1[4] sdd1[3] sdc1[2]
      17581607424 blocks level 6, 64k chunk, algorithm 2 [11/10] [U_UUUUUUUUU]

Aufatmen, ein letzter Test:

# mount /dev/md0 /mnt/data
# df -ahT
Filesystem    Type    Size  Used Avail Use% Mounted on
/dev/root     ext4     73G  6.9G   63G  10% /
proc          proc       0     0     0   -  /proc
sysfs        sysfs       0     0     0   -  /sys
usbfs        usbfs       0     0     0   -  /proc/bus/usb
tmpfs        tmpfs    1.7G     0  1.7G   0% /dev/shm
/dev/md0       xfs     15T   14T  1.5T  91% /mnt/data

Erleichterung überall. Ich brauche einen Drink ...

Antwort2

Ich hatte 2009 ein ähnliches Problem, habe auf Facebook damit geprahlt und konnte die Lösung dann nicht reproduzieren. Der Datenverlust war allerdings noch schlimmer. Ich poste es für die Nachwelt und für meine eigene Möglichkeit, es zu finden.

Das Problem war etwas anders - gparted sagte, sda1 sei xfs und sda2 sei unbekannt, beide sollten RAID-Partitionen sein und das xfs sollte auf md0 sein

# mdadm --assemble --force /dev/md0 /dev/sda1 /dev/sdb1
# xfs_repair -v /dev/md0
# mount /dev/md0 /mount/myRaid

verwandte Informationen