ext4 eines USB-Sticks reparieren

[Ulidor]

Hallo,

mein verschlüsselter und mit ext4 formatierter USB-Stick scheint beim Checken mit fsck ohne Optionen in Ordnung zu sein. Verwende ich jedoch die Option -f (force), dann sieht das so aus:

Code: Alles auswählen

# fsck -f /dev/mapper/bu11 
fsck from util-linux 2.25.2
e2fsck 1.42.12 (29-Aug-2014)
Durchgang 1: Inodes, Blöcke und Größen werden geprüft
Durchgang 2: Verzeichnisstruktur wird geprüft
Verzeichnis-Inode 3674337, Block Nr.27, Offset 0: Verzeichnis defekt
Retten<j>? ja
Durchgang 3: Verzeichnisverknüpfungen werden geprüft
Durchgang 4: Referenzzähler werden überprüft                                                                   
Durchgang 5: Zusammengefasste Gruppeninformation wird geprüft                                                  
                                                                                                               
/dev/mapper/bu11: ***** DATEISYSTEM WURDE VERÄNDERT *****                                                      
/dev/mapper/bu11: 192910/7823360 Dateien (1.2% nicht zusammenhängend), 22359533/31272704 Blöcke

Wiederhole ich den Befehl, ist das Ergebnis immer wieder exakt das gleiche.

Der Stick lässt sich mounten und in lost+found befindet sich eine 32k große Datei, die eine E-Mail enthält (u.a. viele E-Mails sind auf dem Stick gespeichert):

Code: Alles auswählen

# ls -lh /mnt/x/lost+found/                                                                           
insgesamt 32K                                                                                                  
-r--r--r-- 1 root root 32K Sep  8 16:43 #3674932

Der Stick enthält ein Backup. Solange mein System funktioniert, brauche ich seine Daten nicht (ich habe auch noch mehr Backups). Es geht mir eher ums Prinzip der FS-Rettung, denn ich dachte immer, ein Aufruf von fsck reicht in der Regel, um es zu reparieren.

Wie kann ich das Dateisystem reparieren, ohne neu formatieren zu müssen?

Gruß
Rolf

[DeletedUserReAsG]

Wenn man auf Stick schreibt, das anscheinend fehlerfrei funktioniert hat aber beim erneuten Einlesen die alten Daten wieder da sind, ist das üblicherweise ein Zeichen dafür, dass man sich einen anderen Stick zulegen sollte, weil dieser hier sein Lebensende erreicht hat.

[Ulidor]

Wenn man auf Stick schreibt, das anscheinend fehlerfrei funktioniert hat aber beim erneuten Einlesen die alten Daten wieder da sind, ist das üblicherweise ein Zeichen dafür, dass man sich einen anderen Stick zulegen sollte, weil dieser hier sein Lebensende erreicht hat.

Meinst du die Datei in lost+found mit den alten Daten?

Es wäre jedenfalls ziemlich ärgerlich, wenn der Stick schon sein Lebensende erreicht hätte. Er ist 128GiB groß, erst zwei oder drei Jahre alt, war nicht ganz billig und bekommt nur ca. dreimal im Monat ein Backup per rsync, wobei also nur die Änderungen gespeichert werden. So ein Ding darf doch noch nicht unrettbar kaputt sein, der sollte doch Reserveblöcke haben.

Kann fsck den defekten Inode denn nicht verlagern?

[DeletedUserReAsG]

Meinst du die Datei in lost+found mit den alten Daten?

Ich meine das, was fschk am FS rummalt. Entsprechend:

Kann fsck den defekten Inode denn nicht verlagern?

Wenn sich hardwareseitig an der Stelle nix mehr schreiben lässt, kann Software gar nix machen.

Wenn du viel Zeit hast, und ein Backup (oder in Zockerlaune bist), könntest du mal badblocks mit dem nichtdestruktiven rw-Test drauf loslassen.

[Ulidor]

Wenn du viel Zeit hast, und ein Backup (oder in Zockerlaune bist), könntest du mal badblocks mit dem nichtdestruktiven rw-Test drauf loslassen.

Ich hab erst mal den r-Test gemacht, weil der recht schnell geht. Der hat nichts gefunden. Jetzt läuft der nicht destruktive rw-Test...

Bringt denn der Blocktest überhaupt was? fsck bemängelt doch einen defekten Verzeichnis-Inode.

Was ich auch nicht verstehe: fsck fragt, ob es das Verzeichnis retten soll, was ich bejahe. Beim erneuten Befehlsaufruf kommt aber wieder der gleiche Fehler. Die Rettung ist also fehlgeschlagen, was aber nicht angezeigt wird.

[DeletedUserReAsG]

Wie gesagt, wenn ein USB-Stick an sein Lebensende kommt, kann es passieren, dass Schreibzugriffe nicht mehr wirklich gespeichert werden. Deswegen bringt ein Lesetest in dem Fall gar nichts. Das Ändern der Inodetabelle wäre ein Schreibzugriff – der ja anscheinend fehlerfrei funktioniert, während sich später zeigt, dass eben nicht geschrieben wurde. Daher meine Vermutung.

[Ulidor]

Der rw-Test hat auch keine Fehler angezeigt.
Bei der Fehlermeldung von fsck bin ich davon ausgegangen, dass der Fehler im Inode-Bereich und nicht bei den Blöcken liegt.

Kann ich den Fehler denn jetzt doch nur durch Foramtieren beheben und hoffen, dass er nicht wieder auftaucht? Wie gesagt, das ist ein Backup-Stick und ich habe noch mehr Backups, deshalb sind die Daten nicht so wichtig. Die Frage ist, ob sich der Aufwand lohnt oder ob ich den teuren Stick wirklich abschreiben muss.

[DeletedUserReAsG]

Kann ich den Fehler denn jetzt doch nur durch Foramtieren beheben und hoffen, dass er nicht wieder auftaucht?

Ich würd’s probieren. Nachdem ich den Stick komplett genullt habe.

Bei der Fehlermeldung von fsck bin ich davon ausgegangen, dass der Fehler im Inode-Bereich und nicht bei den Blöcken liegt.

Die Tabelle ist halt wie alle anderen Daten auch auf dem Stick gespeichert.

[Ulidor]

Kann ich den Fehler denn jetzt doch nur durch Foramtieren beheben und hoffen, dass er nicht wieder auftaucht?

Ich würd’s probieren. Nachdem ich den Stick komplett genullt habe.

Der Stick ist doch sowieso verschlüsselt, warum dann erst nullen?

[DeletedUserReAsG]

Um alle Zellen zu leeren, sofern der Stick intakt ist. Tritt danach ein Fehler an der gleichen Stelle auf, ist’s noch sicherer, als jetzt schon, dass der Stick schlicht defekt ist.

[wanne]

Es wäre jedenfalls ziemlich ärgerlich, wenn der Stick schon sein Lebensende erreicht hätte. Er ist 128GiB groß, erst zwei oder drei Jahre alt, war nicht ganz billig und bekommt nur ca. dreimal im Monat ein Backup per rsync, wobei also nur die Änderungen gespeichert werden.

Trotzdem ist ein Stick einfach kein Medium für Backups. Da kommst du an HDDs oder Band einfach nicht vorbei. Da siehst du was passiert

So ein Ding darf doch noch nicht unrettbar kaputt sein, der sollte doch Reserveblöcke haben.

Festplatten haben sowas. Sticks eher nicht. Die sind einfach nicht auf derartig viele Zugriffe ausgelegt.
Schon der Firefox auf SSDs, (die weit mehr mitmachen) führt wohl ganz gerne mal schnell zu EOL.

Kann fsck den defekten Inode denn nicht verlagern?

Ne nachträglich geht da nichts mehr. Du kannst Wegkopieren und danach mit der Option -cc neu formatieren.
Bringt aber bei besseren USB-Stickst nichts, weil die die Schreibzugriffe in gewissen Abständen umverteilen um die Schreibzugriffe besser zu verteilen. Sprich wenn heute Block 1234 kaputt ist, kann der morgen über die Adresse 5678 erreichbar sein. Der Stick Sagt dir aber nie welche Addresse zu welchem Block gehört.
Btw. Sollte das auch dazu führen, dass dir jetzt nach und nach alle Blöcke weitestgehend gleichzeitig kaputtgehen.

[Ulidor]

Btw. Sollte das auch dazu führen, dass dir jetzt nach und nach alle Blöcke weitestgehend gleichzeitig kaputtgehen.

Das befürchte ich. Ich habe den Stick jetzt erst mal neu formatiert. Mal sehen, wie lange er noch durchhält. Ich habe einen zweiten, baugleichen Stick. Die beiden verwende ich immer im Wechsel, der zweite hat also in etwa die gleiche Anzahl an Schreibzugriffen hinter sich. Der wird dann wohl auch bald die erste Macke haben.

Am Rechner hängt eine externe USB3-SSD, auf die bei jedem Herunterfahren ein komplettes Backup per rsync geschrieben wird. Ich hoffe, die ist für mehr Schreibzugriffe ausgelegt als ein Stick.