Menü Schließen

XFS Metadata Corruption Detected nach Raid Crash

Unix Shell

System ist ein Debian Wheezy mit 12x3TB im Raid6. Entsprechend sind aus dem Stablezweig die xfsprogs in Version 3.1.7+b1 installiert. Leider musste ich feststellen, dass die zu alt sind und xfsprogs in Version 4.2 aktueller sind. Diese sollte man hier auch nutzen, da diverse Verbesserungen eingeflossen sind.

Die Fehlermeldung im Serverlog zieht wie folgt aus:

[ 1414.354387] XFS (md2): Metadata corruption detected at xfs_inode_buf_verify+0x6d/0xc0 [xfs], block 0xa160cc000
[ 1414.356087] XFS (md2): Unmount and run xfs_repair
[ 1414.357774] XFS (md2): First 64 bytes of corrupted metadata buffer:
[ 1414.359459] ffff880213bc1000: 90 c7 df 1d ab db a2 20 c9 d0 1d b4 63 36 51 8c

Ursache ist eine Festplatte im Raid die über 700 Badblocks aufwies und ausgestiegen ist. Ganz klar hier muss man sich nicht viel vormachen, das ganze wird mit einem Datenverlust einher gehen. Daher ist ein Backup immer ratsam. Mir gehts nur noch darum, nicht alle Daten zu verlieren und daher fahre ich wie folgt fort:

Zuerst alle Dienste Stoppen und das Dateisystem unmounten

In meinem Fall ist noch ein GlusterFS darüber liegend:

# gluster volume stop vol2
# /etc/init.d/glusterfs-server stop
# umount /mnt/mountpunkt

Bevor auf das XFS Dateisystem geschrieben wird, empfiehlt es sich eine Prüfung (Option -n) von xfs_repair durchlaufen zu lassen. Am Ende wird anzeigt welche Änderungen gemacht werden müssen:
# xfs_repair -n -vv /dev/md2

Die Ausgabe sieht dann wie folgt aus:

Inode-Allokations-btrees sind zu beschädigt, Phasen 6 und 7 werden
übersprungen
Kein Änderungskennzeichen gesetzt, Leeren des Dateisystems wird
übersprungen und es wird beendet

XFS_REPAIR Zusammenfassung    Fri Oct 16 18:06:41 2015

Phase        Start        Ende        Dauer
Phase 1:    10/16 18:05:15    10/16 18:05:18    3 Sekundes
Phase 2:    10/16 18:05:18    10/16 18:05:20    2 Sekundes
Phase 3:    10/16 18:05:20    10/16 18:06:11    51 Sekundes
Phase 4:    10/16 18:06:11    10/16 18:06:41    30 Sekundes
Phase 5:    Übersprungen
Phase 6:    Übersprungen
Phase 7:    Übersprungen

Gesamte Laufzeit: 1 Minute, 26 Sekundes

Als nächstes lasse ich das XFS Dateisystem reparieren, jedoch mit Angabe der maximalen Verwendung von 4GB Arbeitsspeicher:
# xfs_repair -vv -m 4096 /dev/md2
Phase 1 – Superblock finden und überprüfen…
– max_mem = 4194304, icount = 506176, imem = 1977, dblock = 8754955776, dmem = 4274880
Required memory for repair is greater that the maximum specified
with the -m option. Please increase it to at least 4225.

OK, 4GB reichen nicht aus. Also kurz mit #free -h nachgesehen wieviel frei ist und auf 5GB erhöht: #xfs_repair -vv -m 5120 /dev/md2
bad version number 0xffffffef on inode 99972628480, Versionsnummer wird zurückgesetzt
Bad flags set in inode 99972628480, fixing bad flags.
bad non-zero extent size 38656 for non-realtime/extsize inode 99972628480, wird auf Null zurückgesetzt
directory inode 99972628480 has bad size 2377934688112103936
cleared inode 99972628480
bad magic number 0x3d3a on inode 99972628481, magische Nummer wird zurückgesetzt
entry “size of last entry overflows space left in in shortform dir 99972628481, es wird auf 44 zurückgesetzt
entry contains illegal character in shortform dir 99972628481
cache_node_put: node put on node (0x7fdba0e3a610) in MRU list
Speicherzugriffsfehler

An dieser Stelle habe ich dann, wie eingangs schon beschrieben ein Upgrade der xfsprogs auf die aktuelle Version 4.2 gemacht. Dies habe ich durch das Upgrade von Wheezy zu Jessie und dann auf Stretch erledigt. Danach habe ich die obigen Schritte nochmals durchlaufen lassen und die Fehler wurden behoben, allerdings habe ich ein paar Daten verloren.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert