Laufwerke und Dateisysteme

Btrfs-Prüfsummenfehler und unlesbare Extents

Btrfs-Prüfsummenmeldungen mit Scrub-Ergebnis und Redundanz auswerten und beschädigte Daten sichern; Scrub repariert keine fehlende gültige Kopie.

Auf dieser Seite
  1. Symptome und Geltungsbereich
  2. Mögliche Ursachen
  3. Sicher prüfen
  4. Nächste Schritte nach Befund
  5. Quellen und Prüfung
  6. Verwandte Probleme

Symptome und Geltungsbereich

  • Eine Datei liefert EIO und der Kernel meldet csum failed.
  • Ein vorhandener Scrub-Status enthält nicht korrigierbare Fehler.

Betroffene Umgebung

Btrfs mit Prüfsummen für Daten oder Metadaten; NOCOW/NODATASUM-Dateien können anders abgedeckt sein.

Erkennbare Meldungen (synthetische Beispiele)
BTRFS warning (device sdb2): csum failed root 5 ino 812 off 0 csum 0x12345678 expected csum 0x87654321 mirror 1

Inode und Offset möglichst zuordnen; vorhandene Replikate bestimmen, ob automatische Reparatur möglich ist.

BTRFS error (device sdb2): checksum verify failed on logical 1048576 mirror 1 wanted 0x1234 found 0x5678 level 1

Metadatenschäden können viele Dateien betreffen; ein Abbild sichern und Geräte- sowie RAM-Befunde prüfen.

Mögliche Ursachen

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

  • Gespeicherte Daten weichen von ihrer Prüfsumme ab; Medien-, Übertragungs-, RAM- oder Softwarefehler sind möglich und benötigen eigene Befunde.
  • Redundanz ermöglicht Reparatur nur bei vorhandener gültiger Ersatzkopie; ein einzelnes Gerät bedeutet nicht automatisch für alle Metadaten ein Single-Profil.

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

/mountpoint durch das betroffene Btrfs-Mount ersetzen. Vorhandene Scrub-Ergebnisse lesen, ohne einen Scan zu starten.

sudo btrfs scrub status /mountpoint

Ergebnis einordnen: Corrected errors bedeutet Nutzung einer gültigen Kopie; uncorrectable errors erfordert Rettung aus anderer Quelle. Ein fehlender vorheriger Scrub ist kein Integritätsnachweis.

Prüfschritt 2

Dauerhafte Btrfs-Gerätezähler lesen. Der Befehl enthält kein -z und setzt sie nicht zurück.

sudo btrfs device stats /mountpoint

Ergebnis einordnen: Corruption errors stützt Prüfsummenprobleme; read/write/flush errors zeigen zusätzliche Geräte-I/O-Störungen. Änderungen über Zeit vergleichen, da alte Zähler bestehen bleiben.

Nächste Schritte nach Befund

Daten sichern und fehlerhaften Pfad verfolgen

Bei nicht korrigierbaren Fehlern lesbare Dateien sichern und genannte beschädigte Dateien unabhängigen Backups zuordnen. Gerätefehler und RAM-Stabilität prüfen, bevor neue Schreibzugriffe oder automatische Bereinigung erlaubt werden.

Vorsicht: Fehler nicht durch Löschen von Prüfsummenmetadaten oder btrfs check --repair unterdrücken. Eine Prüfsumme beweist die Abweichung, nicht den ursprünglichen korrekten Bytewert.

Wiederherstellung / Rücknahme: Betroffene Dateien nach Behebung der Ursache aus geprüften unabhängigen Kopien wiederherstellen; das ursprüngliche Rettungsabbild behalten.

Hat dir dieser Hinweis geholfen?

Hinweis teilen#

Scrub nach vorhandener Redundanz planen

Wenn Speicher stabil und Backups vorhanden sind, einen Scrub zur Umfangsbestimmung planen. Normaler Scrub kann aus gültigen Replikaten reparieren; für eine Prüfung ohne gewünschte Änderungen den Nur-Lese-Modus nutzen.

Vorsicht: Scrub erzeugt dauerhafte I/O-Last und ist keine strukturelle Dateisystemprüfung. Bei einem aktiv ausfallenden Laufwerk Daten vor einem Vollscan retten.

Wiederherstellung / Rücknahme: Scrub-Reparatur hat keine allgemeine Rückgängig-Funktion; Backups behalten. Bei zunehmenden Gerätefehlern den Scan abbrechen und auf einer geretteten Kopie weiterarbeiten.

Hat dir dieser Hinweis geholfen?

Hinweis teilen#

Quellen und Prüfung

Diese Anleitung basiert auf Originalquellen von Projekten oder Distributionen und wurde am genannten Datum redaktionell geprüft. Das ist eine Quellenprüfung, kein Nachweis einer auf deiner Hardware reproduzierten Lösung. Log-Beispiele sind synthetische Testdaten. Versionsabhängige Details müssen zur installierten Ausgabe passen.