staging.inyokaproject.org

Hallo,

mit

sudo fsck.ext4 -v -f -c /dev/sda2

kann ich badblocks suchen. Diese werden dann in einem inode gespeichert.

Wie kann ich denn diesen inode auslesen, um zu wissen, welche Blöcke "bad" sind?

Was solls dir denn bringen? Deine UNC kannst du nur schreibend loswerden. Die Daten auf diesen Sektoren sind also so oder so bereits gehimmelt.

Mach ein Backup deiner Daten und dann wisch mit dem Zewa mal drüber. Wisch und Weg mit dd, DBAN, Secure-Erase, ...

Dogeater schrieb:

Was solls dir denn bringen?

Dann kann ich feststellen, welche Datei(en) das betrifft.

Deine UNC kannst du nur schreibend loswerden.

Versteh nix!

Die Daten auf diesen Sektoren sind also so oder so bereits gehimmelt.

Klar!

Mach ein Backup deiner Daten und dann wisch mit dem Zewa mal drüber. Wisch und Weg mit dd, DBAN, Secure-Erase, ...

Davon wird der kaputte Sektor auch nicht heile, oder?

UlfZibis schrieb:

Dann kann ich feststellen, welche Datei(en) das betrifft.

Das wird dir beim Kopieren der Daten sicher auffallen.

Deine UNC kannst du nur schreibend loswerden.

Versteh nix!

UNC bedeutet, dass der Sektor nicht mehr korrekt ausgelesen werden kann. Das bedeutet aber nur eventuell, das der Sektor irreparabel zerstört ist. Du kannst ihn eventuell reparieren, indem du ihn mit korrekten Daten überschreibst.

Mach ein Backup deiner Daten und dann wisch mit dem Zewa mal drüber. Wisch und Weg mit dd, DBAN, Secure-Erase, ...

Davon wird der kaputte Sektor auch nicht heile, oder?

Doch, eventuell.

Ich weiß ja nicht, was bei UlfZibis genau für ein Szenario vorliegt. Bei einer größeren Zahl von "bad blocks" würde ich nichts analysieren oder reparieren, sondern die Platte ersetzen.

Dogeater schrieb:

UlfZibis schrieb:

Dann kann ich feststellen, welche Datei(en) das betrifft, und muss mich nur um die kümmern ... und finde sie dann hoffentlich noch irgendwo als Backup.

Das wird dir beim Kopieren der Daten sicher auffallen.

Das ist aber weder die schnelle noch die elegante Methode. 👿 Schade, dass da niemand einen Hinweis für hat.

UNC bedeutet, dass der Sektor nicht mehr korrekt ausgelesen werden kann. Das bedeutet aber nur eventuell, das der Sektor irreparabel zerstört ist. Du kannst ihn eventuell reparieren, indem du ihn mit korrekten Daten überschreibst.

Beim Schreiben wird aber doch anschließend nicht automatisch auf Erfolg geprüft, soweit ich das in Erinnerung habe. Da finde ich es besser, erst mal wirklich kaputte Blöcke mittels fsck.ext4 zu sperren.

Mach ein Backup deiner Daten und dann wisch mit dem Zewa mal drüber.

Wenn ich es richtig überblicke, waren nur Blöcke auf der System-Partition betroffen, die /home-Partition scheint glücklicherweise unbeschadet. ♥

Thomas_Do schrieb:

Ich weiß ja nicht, was bei UlfZibis genau für ein Szenario vorliegt. Bei einer größeren Zahl von "bad blocks" würde ich nichts analysieren oder reparieren, sondern die Platte ersetzen.

Sollte ja nur für eine Übergangszeit sein. Mittlerweile bin ich auf einer neuen Platte. Die macht aus meinem 13 Jahre alten T500 mit dem komfortablen 16:10-Bildschirm noch mal einen richtigen Renner. 🦆

UlfZibis schrieb:

Dogeater schrieb:

UNC bedeutet, dass der Sektor nicht mehr korrekt ausgelesen werden kann. Das bedeutet aber nur eventuell, das der Sektor irreparabel zerstört ist. Du kannst ihn eventuell reparieren, indem du ihn mit korrekten Daten überschreibst.

Beim Schreiben wird aber doch anschließend nicht automatisch auf Erfolg geprüft, soweit ich das in Erinnerung habe. Da finde ich es besser, erst mal wirklich kaputte Blöcke mittels fsck.ext4 zu sperren.

Inwiefern ist es gut, von defekten Dateien lesen zu können?

Mach ein Backup deiner Daten und dann wisch mit dem Zewa mal drüber.

Wenn ich es richtig überblicke, waren nur Blöcke auf der System-Partition betroffen, die /home-Partition scheint glücklicherweise unbeschadet. ♥

Na also. Dann mal ran. Wisch und Weg damit.

Dogeater schrieb:

UlfZibis schrieb:

Dogeater schrieb:

UNC bedeutet, dass der Sektor nicht mehr korrekt ausgelesen werden kann. Das bedeutet aber nur eventuell, das der Sektor irreparabel zerstört ist. Du kannst ihn eventuell reparieren, indem du ihn mit korrekten Daten überschreibst.

Beim Schreiben wird aber doch anschließend nicht automatisch auf Erfolg geprüft, soweit ich das in Erinnerung habe. Da finde ich es besser, erst mal wirklich kaputte Blöcke mittels fsck.ext4 zu sperren.

Inwiefern ist es gut, von defekten Dateien lesen zu können?

Ich fürchte, wir reden jetzt aneinander vorbei. Ich wollte feststellen, welche Datei(en) von den sehr wenigen Blöcken betroffen sind. Dann habe ich letztere mittels fsck.ext4 -v -f -c im Dateisystem sperren lassen, damit sie nicht mehr benutzt werden. Hätte ich gewusst, welche Datei(en) betroffen waren, hätte ich nur diese neu schreiben müssen. Da das nicht der Fall war, musste ich gemäß Paketverwaltung/Problembehebung (Abschnitt „Saemtliche-Pakete-neu-installieren“) vorgehen, was über 24 Std. gedauert hat.

Wäre ich Deinem Vorschlag (einfach überschreiben in der Hoffnung dass die Blöcke sich selbst reparieren) gefolgt, also auf fsck.ext4 -v -f -c zu verzichten, dann könnte es passieren, dass wieder Dateien in die defekten Blöcke geschrieben werden, ohne das es zunächst auffällt, dass sie evtl. später nicht mehr lesbar sind. Deshalb schrieb ich: "Beim Schreiben wird aber doch anschließend nicht automatisch auf Erfolg geprüft, soweit ich das in Erinnerung habe."

Mach ein Backup deiner Daten und dann wisch mit dem Zewa mal drüber.

Wenn ich es richtig überblicke, waren nur Blöcke auf der System-Partition betroffen, die /home-Partition scheint glücklicherweise unbeschadet. ♥

Na also. Dann mal ran. Wisch und Weg damit.

Was eine komplette Neuinstallation bedeutet hätte. Ziemlicher Aufwand ohne die Gewähr, dass ich dabei auch an alles gedacht hätte, was ich in den letzten 2 Jahren dazuinstalliert und umkonfiguriert habe. ... Und das alles, um sie eh nur noch ca. 1 Woche zu benutzen, bis ich eine neue Festplatte besorgt habe.

UlfZibis schrieb:

[…] Wie kann ich denn diesen inode auslesen, um zu wissen, welche Blöcke "bad" sind?

sudo dumpe2fs -b 

UlfZibis schrieb: Deshalb schrieb ich: "Beim Schreiben wird aber doch anschließend nicht automatisch auf Erfolg geprüft, soweit ich das in Erinnerung habe."

Ok, jetzt wird die Sache klarer. Es ist so, die defekten Sektoren werden mithilfe des Überschreibens repariert. Dein Dateisystem hat damit nichts zu tun, denn die Daten holst du natürlich soweit es geht schon vorher runter. Du hast ja jetzt kein zerschossenes Dateisystem, bei dem andere Maßnahmen notwendig geworden wären. Außerdem ist laut deiner Aussage nur die Systempartition betroffen, die wird umso schneller repariert werden können. Natürlich werden die Sektoren dabei überprüft, da arbeiten alle Programme recht ähnlich. Unterschiede gibt es aber bei der Fähigkeit, aufs Remapping der Firmware einzuwirken. So weit musst du jedoch mMn nicht gehen.

Was allerdings sein kann ist, dass sich noch defekte Sektoren irgendwo verstecken, von denen du und selbst die Festplatte noch nicht wissen. Wenn du deine Daten also irgendwann runtergeholt hast, dann kannst du die gesamte Platte putzen, dabei werden natürlich entsprechende Ergebnisse zutage kommen, ob die Platte wirklich defekte (so richtig defekte) Sektoren hat oder ob doch nicht eher der tolle Blitzeinschlag bei deinem Nachbarn oder der letzte Systemabsturz an dem falsch beschriebenen Sektor schuld ist.

Mach ein Backup deiner Daten und dann wisch mit dem Zewa mal drüber.

Wenn ich es richtig überblicke, waren nur Blöcke auf der System-Partition betroffen, die /home-Partition scheint glücklicherweise unbeschadet. ♥

Na also. Dann mal ran. Wisch und Weg damit.

Was eine komplette Neuinstallation bedeutet hätte. Ziemlicher Aufwand ohne die Gewähr, dass ich dabei auch an alles gedacht hätte, was ich in den letzten 2 Jahren dazuinstalliert und umkonfiguriert habe. ... Und das alles, um sie eh nur noch ca. 1 Woche zu benutzen, bis ich eine neue Festplatte besorgt habe.

Tu nicht so, als wenn deine ganzen hunderte unnnnd aaaberhunderte von Konfigurationsdateien auf defekten Sektoren liegen. 😉 Die kannst du natürlich sichern. Und wenn du sie brauchst, hast du sie ja parat dann. Es geht schneller als du glaubst, ich habe mir auch meine eigenen Sachen für jede Neuinstallation zurechtgelegt und bequem abarbeitbar gemacht hier. Ich würde mir jedenfalls keine 24h Arbeit machen. Du wirst dir nämlich nochmal zusätzlich dazu Arbeit obendrauf machen, wie ich dich einschätze, bist du ja noch garnicht fertig. Das ist doch verschwendete Mühe, bei Ubuntu brauchst du die Neuinstallation nicht scheuen!

kB schrieb:

sudo dumpe2fs -b 

Super danke!

Wie vorauszuahnen wurde genau ein Block (13071) vom vorherigen fsck.ext4 -v -f -c als "bad" markiert.

Jetzt schließt sich gleich noch eine 2. Frage an. Wie finde ich heraus, welche Datei diesen defekten Block benutzt hat? Diese wird ja unbrauchbar sein, sodass ich sie von woanders neu besorgen muss, um sie dem System wieder korrekt zufügen zu können.

Dogeater schrieb:

UlfZibis schrieb: Deshalb schrieb ich: "Beim Schreiben wird aber doch anschließend nicht automatisch auf Erfolg geprüft, soweit ich das in Erinnerung habe."

Ok, jetzt wird die Sache klarer. Es ist so, die defekten Sektoren werden mithilfe des Überschreibens repariert.

Das ist aber Glücksache. Ein physikalisch kaputter Sektor bleibt kaputt. Wenn das Dateisystem nichtsahnend den für eine Datei benutzt, erfahre ich davon nichts, es sei denn, ich mounte das Dateisystem dauerhaft als "verify after write". Das hat aber den gravierenden Nachteil, dass das System dadurch um mindestens Faktor 2 langsamer wird. Deshalb wird das üblicherweise nicht gemacht.

Dein Dateisystem hat damit nichts zu tun,

Nur insofern, dass als physikalisch defekt erkannte Blöcke im DS als gesperrt markiert werden können, damit sie nicht mehr benutzt werden.

denn die Daten holst du natürlich soweit es geht schon vorher runter.

Es geht hier ja nicht wirklich um Daten, sondern um Dateien vom System. Wenn ich feststellen kann, welcher Block defekt ist und welche Datei davon betroffen ist, dann kann ich den Block sperren, und die Datei ersetzen – welche dann notwendigerweise woandershin geschrieben wird – und schon wäre ich fertig und hätte wieder ein in allen Aspekten lauffähiges System, zumindest eine Zeitlang. Genau das war mein Ziel.

Du hast ja jetzt kein zerschossenes Dateisystem, bei dem andere Maßnahmen notwendig geworden wären. Außerdem ist laut deiner Aussage nur die Systempartition betroffen, die wird umso schneller repariert werden können. Natürlich werden die Sektoren dabei überprüft, da arbeiten alle Programme recht ähnlich.

Unter fsck.ext4 werden mit -c nicht lesbare Blöcke ermittelt und für weitere Benutzung gesperrt. Dateien, die davon betroffen sind (und damit eh kaputt sind), sind dann nicht mehr nutzbar und müssen ersetzt werden. Mit zweimal -c werden die Blöcke mit einer nicht-Daten-zerstörenden Methode auch auf Beschreibbarkeit geprüft. Das hätte ich wohl besser gemacht, denn nur so fallen alle physikalisch kaputten Sektoren auf. Dateien müssen für beide Methoden nicht vorher gesichert werden.

Was allerdings sein kann ist, dass sich noch defekte Sektoren irgendwo verstecken, von denen du und selbst die Festplatte noch nicht wissen.

Das wird mit fsck.ext4 -f -c -c erledigt.

Tu nicht so, als wenn deine ganzen hunderte unnnnd aaaberhunderte von Konfigurationsdateien auf defekten Sektoren liegen. 😉 Die kannst du natürlich sichern. Und wenn du sie brauchst, hast du sie ja parat dann.

Es sind sicher nicht hunderte, aber auch wenn es nur 30 sind, muss ich sie ja erst einmal vollständig finden, und das kann dauern.

Es geht schneller als du glaubst,

Die Realität hat meinen Glauben immer wieder erschüttert. Die jetzige Neuinstallation von 20.04 hat mich eine Woche gekostet. Für eine 18.04 wollte ich das nicht auch noch mal machen.

ich habe mir auch meine eigenen Sachen für jede Neuinstallation zurechtgelegt und bequem abarbeitbar gemacht hier.

Hab' ich auch (siehe Anhang und beachte, dass darin noch auf ein paar Extra-Anleitungen verwiesen wird). Dennoch klemmt's immer mal irgend wo, weil PPAs nicht mehr gültig sind, die Wine-Installation sich mal wieder geändert hat, man sich Nemo von Mint besorgen muss, Erweiterungen nicht mehr zu kriegen sind, ich diverse Entwicklerversionen neu konfigurieren und kompilieren muss, meine älteren Drucker und der Scanner nicht ganz unkompliziert wieder zu Laufen zu kriegen sind (Entwickler-Patch von sane und xsane nöig), etc. pp.... Mal ganz abgesehen davon, das JPilot und FSlint aus 20.04. rausgeschmissen wurden. Echt Mist, dass ich nur dafür eine 18.04 am Laufen halten muss.

Du wirst dir nämlich nochmal zusätzlich dazu Arbeit obendrauf machen, wie ich dich einschätze, bist du ja noch gar nicht fertig.

Haha, hast mich durchschaut 🤣

Das ist doch verschwendete Mühe,

... zahlt sich aber früher oder später wieder aus

UlfZibis schrieb:

[…] Wie finde ich heraus, welche Datei diesen defekten Block benutzt hat?

Es läuft wohl darauf hinaus, für jeden Dateinamen den Inode aufzusuchen und nachzuschauen, ob darin direkt oder indirekt oder doppelt indirekt der defekte Block auftaucht. Und dann gibt es auch noch die Extents. Das klingt nicht nach einem sehr effektiven Verfahren. Vielleicht hat fsck eine Option dafür, oder debugfs. Dessen Befehl icheck beschafft Dir wohl die Inode zur Blocknummer, wenn ich es richtig verstehe.

UlfZibis schrieb:

Ok, jetzt wird die Sache klarer. Es ist so, die defekten Sektoren werden mithilfe des Überschreibens repariert.

Das ist aber Glücksache. Ein physikalisch kaputter Sektor bleibt kaputt.

Du benutzt die falsche Software.

Wenn das Dateisystem nichtsahnend den für eine Datei benutzt, erfahre ich davon nichts, es sei denn, ich mounte das Dateisystem dauerhaft als "verify after write". Das hat aber den gravierenden Nachteil, dass das System dadurch um mindestens Faktor 2 langsamer wird. Deshalb wird das üblicherweise nicht gemacht.

Genau deswegen Zewa Wisch und Weg, damit solche Sektoren nicht mehr da sind!

Dein Dateisystem hat damit nichts zu tun,

Nur insofern, dass als physikalisch defekt erkannte Blöcke im DS als gesperrt markiert werden können, damit sie nicht mehr benutzt werden.

Nein, die werden natürlich mit brutaler Gewalt vernichtet. Oder arbeitest du bei den Vereinten Nationen und darfst das nicht? Bei mir werden die defekten Blöcke unverzüglich verfolgt und hingerichtet. ☺

denn die Daten holst du natürlich soweit es geht schon vorher runter.

Es geht hier ja nicht wirklich um Daten, sondern um Dateien vom System. Wenn ich feststellen kann, welcher Block defekt ist und welche Datei davon betroffen ist, dann kann ich den Block sperren, und die Datei ersetzen – welche dann notwendigerweise woandershin geschrieben wird – und schon wäre ich fertig und hätte wieder ein in allen Aspekten lauffähiges System, zumindest eine Zeitlang. Genau das war mein Ziel.

Oder du installierst neu und gewöhnst dich an ein modernes Betriebssystem. Vielleicht hilft das, den alten Kram abzuschütteln, den du dir da mitschleppst, da oben. Jesses.

kB schrieb:

[…] Wie finde ich heraus, welche Datei diesen defekten Block benutzt hat?

Es läuft wohl darauf hinaus, für jeden Dateinamen den Inode aufzusuchen und nachzuschauen, ob darin direkt oder indirekt oder doppelt indirekt der defekte Block auftaucht. Und dann gibt es auch noch die Extents. Das klingt nicht nach einem sehr effektiven Verfahren. Vielleicht hat fsck eine Option dafür, oder debugfs. Dessen Befehl icheck beschafft Dir wohl die Inode zur Blocknummer, wenn ich es richtig verstehe.

Ja, letzteres bringt die gewünschte Information und erfordert wohl das, was Du im 1. Satz geschrieben hast, denn die Antwort brauchte eine Minute. Hat man den betreffenden Inode, dann lässt sich daraus auch die betroffene Datei ermitteln. Danke für's Raussuchen.

Ich bin jetzt nochmal mit fsck.ext4 -vfpccz fsck_undo.log -C 0 drüber gegangen. Es wurde wieder nur der Block 13071 als defekt ermittelt. Es ist also noch nicht Hopfen und Malz verloren mit dieser Festplatte.

In meinem Fall ergab sich, dass der Block 13071 nicht benutzt wird. War ja auch zu erwarten, denn ich hatte ja nach dem Sperren der bad blocks hiermit alles neugeschrieben. Wie sich zeigt, wurde der gefundene defekte Block dabei korrekterweise nicht mehr benutzt.

Ich frag' mich nun, ob fsck.ext4 -c nicht vielleicht so schon versucht, die von einem bad block betroffene Datei an eine andere Stelle zu retten, bzw. bei Misslingen eine Meldung zu machen. Wäre doch ziemlich logisch, weil fsck.ext4 da doch gleich an der Quelle aller Informationen ist, und damit auch dem beworbenen Zweck "Reparatur" gerecht käme. Mit anderen Worten, meine akribische Suche nach dem richtigen Befehl etc. hätte ich mir vielleicht sparen können, genauso wie das Paketverwaltung/Problembehebung (Abschnitt „Saemtliche-Pakete-neu-installieren“).