Suchen von Dateien mit BTRFS-Fehlern

17

Ich habe eine Frage zu nicht behebbaren Fehlern in einem BTRFS-Dateisystem. Insbesondere habe ich kürzlich ein BTRFS-Scrub ausgeführt, nachdem ein Problem mit einem meiner RAM-Sticks aufgetreten ist und 4 nicht korrigierbare Fehler festgestellt zu haben scheinen. Dies ist die Ausgabe:

scrub status for <UUID>
    scrub started at Thu Dec 25 15:19:22 2014 and was aborted after 89882 seconds
    total bytes scrubbed: 1.87TiB with 4 errors
    error details: csum=4
    corrected errors: 0, uncorrectable errors: 4, unverified errors: 0

Glücklicherweise habe ich alles in einem Tertiär-Backup gesichert, sodass ich mir keine Gedanken über den Verlust der Dateien mache. (Ich bin mir der Probleme im Zusammenhang mit dem experimentellen Status von BTRFS bewusst. Ich habe mehrere Backups, um meine Daten sicher zu halten, und bin fest entschlossen, dies zu tun bitte nicht weiter benutzen: "Lösung; keine BTRFS-Beiträge verwenden").

Ich möchte jedoch wissen, wie ich feststellen kann, welche Dateien mit den nicht korrigierbaren Fehlern verbunden sind. Ich möchte sie finden, löschen und durch ihre gesicherten Kopien ersetzen.

Wenn jemand Informationen dazu hat, würde ich gerne von Ihnen hören.

Danke im Voraus.

backup filesystems btrfs

— RedHack
quelle

8

Ich fand die folgende Methode nützlich ...

btrfs scrub die Lautstärke.

Wie oben gezeigt, wird eine beliebige Anzahl von csum-Fehlern angezeigt.
Verwenden Sie Ihre Beispielfehlerdetails : csum = 4 . Verwenden Sie diese Nummer in der Anweisung tail der folgenden Anweisung:

dmesg | grep "checksum error at" | tail -4 | cut -d\  -f24- | sed 's/.$//'

Es ist praktisch, dies in eine Datei auszuleiten (zB > csums.txt)

Ich habe eine Reihe der vorgeschlagenen Inode-Suchansätze ausprobiert und sie haben alle nur begrenzten Erfolg gehabt, wenn überhaupt.

— Kennzeichen
quelle

— folgt zu entfernen

3

Ja, die Zuordnung von INODE oder Blocknummer zurück zu einem Dateinamen kann schwierig sein. Wenn Sie wirklich interessiert sind, können Sie so etwas ausprobieren und sehen, welche Dateien kopiert werden sollen. Wenn die Datei fehlerhaft ist, sollte sie während des Kopierens einen Fehler auslösen. Ich habe vorher diese Art von Technik verwendet.

 find /mount-point -type f -exec cp {} /dev/null \;

 where mount-point is the ROOT node/mount-point of the affected filesystem

— mdpc
quelle

Wenn Sie es jetzt ausführen, wird hoffentlich etwas auftauchen. Vielen Dank für Ihren Rat. Ich werde Sie über das Ergebnis auf dem Laufenden halten.

— RedHack

1

Es tut uns leid zu sagen, dass es nicht zu funktionieren scheint = / es hat die erste Datei gefunden, die den nicht korrigierbaren Fehler verursacht, aber dann spammt es die Nachricht: "Veraltete Dateizugriffsnummer" an das Terminal, es sei denn, ich beende es. Zugegeben, es hat die Datei gefunden, aber jetzt kann ich nicht herausfinden, wie ich sie loswerden kann. Ich muss mich an die BTRFS-Mailingliste wenden.

— RedHack

Sie können es in ein spezielles Verzeichnis verschieben und dann von einer weiteren Suche ausschließen.

— mdpc

1

Es wird nicht verschoben oder kopiert, sondern es wird mir immer wieder mitgeteilt, dass das Dateihandle veraltet ist. Ich kann nicht einmal ls.

— RedHack

Wenn Sie verwenden cp -v, können Sie überwachen auch den Fortschritt: find / -type f -exec cp -v {} /dev/null \; 2> corrupted-files.txt. Die /proc/kcoreDatei ist jedoch möglicherweise sehr groß (meine war 128 TB groß), sodass der Kopiervorgang wahrscheinlich hängen bleibt. Da das /procVerzeichnis spezielle magische Dateien enthält, müssen wir nicht nach ihnen suchen. Schließen Sie das /procVerzeichnis aus:sudo find / -type f -and -not -path /proc -exec cp -v {} /dev/null \; 2> corrupted-files.txt

— Zeremonie

2

dmesggibt Ihnen Einzelheiten zu den Dateien, die an den nicht korrigierbaren Prüfsummenfehlern beteiligt sind. Die Meldungen sehen normalerweise so aus: "BTRFS: Prüfsummenfehler bei logischen [...] auf [...] dev, sector [...], root [...], inode [...], offset [...] ...], Länge [...], Links [...] (Pfad: [...]) "; Die letzte Information ist der absolute Pfad zu der Datei, die beschädigt ist.

— arrrr
quelle

1

Ich bin hierher gekommen, um nach dem "nicht korrigierbaren Fehler" von BTRFS zu suchen. Das obige grep hat bei mir nicht funktioniert; Ich musste stattdessen verwenden:

$ dmesg | sed -n -r 's#.*BTRFS.*i/o error.*path: (.*)\)#\1#p' | sort -u
somepath/somefile.txt

Beachten Sie, wie der Pfad relativ zum Anfang des Subvolumes ist - keine Angabe, in welchem Subvolume er sich befindet. Dies war für mich zum Glück kein Problem.

— Kreuzritter
quelle

Was ist somepath/somefile.txt? Es sieht so aus, als würden Sie es als separaten Befehl eingeben - oder ist es die Ausgabe des von Ihnen eingegebenen Befehls? Wenn es sich nur um eine Befehlszeile handeln soll, brechen Sie die Befehlszeilen für Anzeigezwecke nicht auseinander, sondern geben Sie sie einfach als eine lange Zeile in die Antwort ein. Aber was ist es? Bieten Sie zwei Eingaben an sort(eine Pipe und eine Datei)? Oder soll somepath/somefile.txtes eine Ausgabedatei sein? (Es ist nicht sehr hilfreich, Ausgabedateien anzugeben, es sei denn, es handelt sich um Zwischendateien, die Sie erneut verwenden. Die

— Scott,

Beantwortet dies die ursprüngliche Frage? Ich kann es nicht sagen.

— Ich sage Reinstate Monica

@TwistyImpersonator Nun, es ist (IMO) eindeutig als Alternative zu Marks Antwort gedacht , und das hat acht Stimmen (und ist eine Erweiterung der Antwort von arrrr ).

— Scott

1

@Scott die zweite Zeile war eine Beispielausgabe des Befehls.

— Kreuzritter