XFS-Filesystem Superblock kann nicht gefunden werden

[kos]

Hallo,

auf meinem Fileserver habe ich eine LVM-Konfiguration mit XFS als Filesystem. Nun habe ich das Problem, dass ich während dem Betrieb mitunter folgenden Fehler erhalten habe:

Code: Select all

rsync: readlink_stat("/data/downloads/beispiel") failed: Structure needs cleaning (117)

Also habe ich das Dateisystem per umount ausgehängt und versucht mittels xfs_repair zu reparieren und dabei folgende Ausgabe erhalten:

Code: Select all

# sudo xfs_repair /dev/mapper/quantum-downloads
Phase 1 - Superblock finden und überprüfen...
primärer Superblock kann nicht überprüft werden - nicht genug sekundäre Superblöcke mit passender Geometrie !!!

es wird versucht einen zweiten Superblock zu finden...
...... ein haufen von dots ...........................Entschuldigung, gültiger zweiter Superblock kann nicht gefunden werden
Wird beendet.

Daraufhin habe ich mal xfs_check ausgeführt:

Code: Select all

# sudo xfs_check /dev/mapper/quantum-downloads

cache_node_purge: refcount was 1, not zero (node=0xd46610)
xfs_check: Wurzel-Inode (117) kann nicht gelesen werden
cache_node_purge: refcount was 1, not zero (node=0xd495d0)
xfs_check: Echtzeit-Bitmap-Inode (117) kann nicht gelesen werden
XFS: Log inconsistent (didn't find previous header)
XFS: failed to find log head
FEHLER: Protokoll head/tail wurde nicht gefunden, führen Sie xfs_repair
aus

Wenn ich nun versuche das Volume wieder zu mounten:

Code: Select all

# sudo mount -o ro,norecovery /dev/mapper/quantum-downloads /data/downloads
mount: Die Struktur muss bereinigt werden

Aktuell kann ich also das Dateisystem garn icht mehr nutzen.
Habe auch schon mal nach Google-Konsultation versucht xfs_repair -L aufzurufen, hat jedoch keine andere Ausgabe ergeben als oben bereits genannt.

Gibt es nun noch irgend welche Möglichkeiten das Dateisystem wieder zum laufen zu bringen, oder bleibt mir nix anderes übrig als es komplett zu überschreiben und damit die Daten zu verlieren?
Es sind aus mir unbekannten Gründen scheinbar mehrere LVM-Volumes betroffen, möchte diese aber aktuell nicht unmounten da ich befürchte das ich dort das selbe Problem bekomme und aktuell noch darauf zugreifen kann.


Vorab vielen Dank für Eure Unterstützung!


Viele Grüße
Karsten

[daemotron]

Moin, ein defekter Superblock bei XFS ist ein sehr heikles Problem; meist lässt sich das FS dann nicht mehr reparieren. Mit einem Forensik-Tool kann man vielleicht noch die Dateien recovern, allerdings unterstützen die mir bekannten Forensik-Toolkits wie z. B. Sleuthkit/TASK XFS leider nicht. Ich drück jetzt mal die Daumen, dass Du ein halbwegs aktuelles Backup hast... Auf jeden Fall mal mit ddrescue ein Image von den betroffenen Volumes ziehen, an denen (bzw. Arbeitskopien davon) kann man vielleicht noch was ausrichten.

Der defekte Superblock ist aber nicht Ursache des Problems, sondern eine nachgelagerte Wirkung - normalerweise passiert sowas, wenn entweder an den (unteren) Partitionsgrenzen rumgefummelt wurde, oder wenn die Platte den Hardware-Tod zu sterben beginnt. Ich würde also dringend empfehlen, die beteiligten Platten mal mit den Smartmontools zu prüfen...

[kos]

Hallo daemotron,

danke für deine schnelle Antwort. Dann werde ich es wohl mal mit ddrescue versuchen.

Eigentlich kann es nicht an der Hardware liegen, da das LVM auf einem RAID6 Verbund (mittels Adaptec Hardware Raid-Controller) sitzt.
Laut dem StorMan-Tool oder auch arcconf Ausgabe sind die Platten alle in Ordnung. Ich hatte nur letzte Woche das Problem das eine Platte wohl irgendwie Probleme gemacht (aber keine Smartmon Errors) hat und habe die unterm Betrieb getauscht. Der Rebuild wurde dann automatisch angestoßen.
Das System hing sehr stark und die Platte stand unter Vollast bevor ich sie getauscht hatte, aber der Controller hat diese irgendwie nicht als "defekt" erkannt und versucht damit weiter zu arbeiten.
Könnte das eventuell damit zu tun haben?
Ich sehe auch gerade das Dateisystem-Problem ist erst aufgetreten nachdem ich die Platte getauscht habe und sich der HW-Controller noch im Background-Rebuild befand.

Auch kann ich vermutlich ausschließen das ich an den "unteren" Partitionsgrenzen (welche das auch sein mögen) rumgefummelt habe, da es mehrere Volumes betrifft.

[Joe User]

Eine Platte muss zuerst sauber aus dem RAID-Verbund abgemeldet werden, bevor man sie entnimmt. Somit hast Du die darauf folgenden Probleme selbst verursacht und mit Pech auch Daten verloren.
Merke Dir das bitte für die Zukunft: Erst Manual lesen, dann nachdenken, dann einen (Notfall-)Plan erstellen, dann testen und erst dann loslegen.

Mit Glück kann ddrescue etwas retten, eventuell auch dd_rescue (ja, sind unterschiedliche Tools), wobei es bei einem Hardware-RAID mit den Metadaten Probleme geben wird und die Daten vermutlich bereits im Nirvana sind.

[kos]

hot swap wird explizit vom controller unterstützt und das betriebssystem war nahezu unnutzbar. ein anderen weg die platte aus dem raid zu entfernen gibt es nicht. im controller bios wird keine option angeboten eine platte zu entfernen.

außerdem, warum solltn bei einem raid6 verbund daten verloren gehen, wenn eine platte ausfällt? dafür hab ich mich doch für raid6 entschieden.

[ddm3ve]

im controller bios wird keine option angeboten eine platte zu entfernen.

außerdem, warum solltn bei einem raid6 verbund daten verloren gehen, wenn eine platte ausfällt? dafür hab ich mich doch für raid6 entschieden.

Lies nochmals das Handbuch. Es gibt mit hoher sicherheit die Möglichkeit eine Platte als defekt zu marieren und damit aus dem Raid verbund zu nehmen. Sonst hätte der Raidkontroller wirklich gar keinen Taug.

btw. auch wenn Ich Deine Haltung dazu nachvollziehen kann:
Eion Raid 5 oder Raid 6 ist so wie ein Airback im Auto niemals ein garant, dass dieser immer und zu jeden Zeitpunkt vollständig fehlerfrei funktioniert.

Deshalb verhält man sich im Wartungsfall auch nicht wie die Axt im Walde und reisst einfach ne Platte aus dem Server, sondern meldet diese sauber ab.

[kos]

Danke, schön und gut, werde ich mir für die Zukunft merken. Auch wenn es bisher immer tadellos in der Vergangenheit geklappt hat.

Aber das ändert nichts an der Tatsache, dass der Fehler bereits vor entfernen der defekten Platte aus dem RAID vorhanden war. Insbesondere, wieso sind dann nur einzelne LVM Volumes betroffen und nicht alle oder die komplette LVM Partition?

Andere Volumes konnte ich mittlerweile normal mittels xfs_repair reparieren (mal von in lost+found gelandeten Dateien/Ordnern abgesehen), aber ein anderes Volume macht auch noch Probleme, dieser bleibt immer nach der selben Stelle der Reparatur stehen und kommt auch nach mehreren Stunden nicht weiter:

Code: Select all

falsche magische # 0xed342f72 in inobt-Block 21/36