XFS schaltet nach Metadaten- oder Log-I/O-Fehlern ab · Linux Fix Lab

Symptome und Geltungsbereich

I/O liefert Fehler, während XFS Shutting down filesystem meldet.
Das Mount bleibt gelistet, normale Zugriffe funktionieren aber nicht mehr.

Betroffene Umgebung

XFS-Daten- oder Root-Dateisysteme, auch auf LVM oder mehrschichtigen Speicheranordnungen.

Erkennbare Meldungen (synthetische Beispiele)

XFS (dm-0): Log I/O Error (0x2) detected at xlog_ioend_work. Shutting down filesystem.

Der vorherige Gerätefehler ist entscheidend; das Log nicht allein für ein erfolgreiches Mount verwerfen.

XFS (sdb1): Corruption of on-disk metadata (0x8) detected at xfs_buf_verifier_error. Shutting down filesystem.

Daten sichern und Speicher- beziehungsweise RAM-Befunde vor einer Offline-Rettung untersuchen.

Mögliche Ursachen

Das sind mögliche Erklärungen, keine bestätigte Diagnose. Mehrere unabhängige Fehler können gleichzeitig vorliegen.

XFS kann nach Log-I/O-Fehlern, Metadatenkorruption oder Geräteentfernung abschalten, um weitere Änderungen zu verhindern.
Auch ein von Userspace angefordertes Abschalten ist möglich; vorherige Meldungen müssen es von einem unerwarteten Fehler unterscheiden.

Sicher prüfen

Führe jeweils einen Befehl in der passenden Sitzung aus. Lies zuerst die Erklärung. Großgeschriebene Platzhalter brauchen deine Werte; Werkzeuge und Rechte unterscheiden sich je nach Distribution. Die Website zeigt Befehle an und führt sie niemals aus.

Prüfschritt 1

XFS- und Quellgeräte-Ereignisse lesen; gegebenenfalls sind Journalrechte nötig. Meldungen vor dem Abschalten erhalten.

journalctl -k -b --no-pager -n 400

Ergebnis einordnen: Log I/O Error oder Metadatenkorruption erklärt schützendes Abschalten; User initiated shutdown received bezeichnet eine angeforderte Aktion.

Prüfschritt 2

/affected/path durch einen vorhandenen Pfad dieses XFS-Mounts ersetzen. Das genaue Geräte- oder Mapper-Ziel lesen.

findmnt -T /affected/path -o TARGET,SOURCE,FSTYPE,OPTIONS

Ergebnis einordnen: Das Abschalten ändert das sichtbare rw-Flag nicht zwangsläufig. Eine Prüfung des falschen LVM-Mitglieds statt des gemappten Dateisystems kann die Rettung fehlleiten.

Nächste Schritte nach Befund

Speicher vor XFS-Log-Wiedergabe stabilisieren

Wenn Protokolle Hardware-I/O-Ausfälle zeigen, Last beenden und zuerst den gestörten Pfad beheben oder auf ein gesundes Gerät retten. Bei stabilem Speicher kann normales Einbinden und sauberes Aushängen ein Dirty Log vor der Offline-Prüfung wiedergeben.

Vorsicht: Log-Wiedergabe ändert Metadaten. Zuerst Abbild oder Backup sichern und weiterhin fehlerhaften Speicher nicht wiederholt einbinden.

Wiederherstellung / Rücknahme: Das unveränderte Abbild behalten. Wenn Wiedergabe oder Einbinden scheitert, abbrechen und mit der gesicherten Kopie weiterplanen.

Hat dir dieser Hinweis geholfen?

Hinweis teilen #

Offline-Reparaturbedarf für XFS prüfen

Wenn Korruption bei stabilem Quellgerät fortbesteht, XFS in einer Rettungsumgebung aushängen und xfs_repair -n auf dem genauen Dateisystemgerät auswerten. Eine tatsächliche Reparatur erst nach Befundprüfung und Datensicherung planen.

Vorsicht: Ein Dirty Log kann die Prüfung blockieren. xfs_repair -L verwirft das Log und kann Dateien verlieren; dies ist eine letzte Rettungsmaßnahme, keine Standardlösung.

Wiederherstellung / Rücknahme: Eine Reparatur lässt sich nicht zuverlässig rückgängig machen. Bei Bedarf gesichertes Abbild oder Backup wiederherstellen und die fehlerhafte Quelle unverändert lassen.