Hallo allerseits,

ich betreibe einen kleinen Linux-Rechner als Heimautomationsserver, der als Speichermedium eine SD-Karte benutzt.

Die produzierte nun nach 5 Jahren zunehmend I/O-Fehler, weswegen ich sie durch eine neue ersetzt habe. Die Daten habe ich in macOS mit dd geklont.

dd listet ja auf, wo es während des Kopierens Lesefehler gab, das war bei insgesamt 143 kB (über 5 Stellen verteilt) von 4 GB der Fall. Das scheint glücklicherweise alles unkritisches Zeugs betroffen zu haben, denn mit der neuen SD-Karte funktioniert alles wieder wunderbar.

Trotzdem frage ich mich natürlich, auch aus prinzipiellem Interesse, ob es eine Möglichkeit gibt herauszufinden, welche Dateien in den betroffenen fehlerhaften Regionen lagen und zerstört wurden.

dd gibt ja die genaue Speicherstelle an, also z.B.


Gibt es irgendeine Möglichkeit, dieser bei 338.632.704 Bytes beginnenden Region eine Datei zuzuordnen (ich habe den Default mit 512k-Blöcken benutzt)?

Wie gesagt, nicht schlimm wenn nicht, aber ich bin neugierig.

Mit einem Hex Editor sollte das funktionieren. Oder einer Recovery Software die das ganze Blockweise ausliest:

Danke! Naheliegende Idee, da hätte ich auch selbst drauf kommen können. Ich habe die Binärdaten in eine Datei in macOS geschrieben (ich musste sie ja in macOS zwischenspeichern, da ich nur einen SD-Kartenleser habe) und habe mir die jetzt mal in einem Hex-Editor angesehen.

Beim ersten fehlenden Block kommt das heraus (der fehlende Block in der Mitte ist leicht zu sehen):

Ist also offenbar irgendein fest in ein Programm eincodierter Hilfstext. Welches Programm, ist mir leider nicht so klar. Und das ist das Hauptproblem bei diesem Verfahren: Wenn an der Stelle nun zufällig Binärcode gewesen wäre, dann würde es mir rein gar nichts nützen, die Bits und Bytes um den fehlenden Block herum zu sehen.

Was man da bräuchte, wäre eine Möglichkeit, mit Hilfe des Dateisystems den Namen der beschädigten Datei herauszufinden, die an dieser Stelle liegt. Da wüsste ich jetzt zumindest nicht, wie das mit einem Hex-Editor gehen soll.

Vielleicht liege ich jetzt ganz falsch aber warum kopierst du nicht mit ditto? Da werden dir auch die Fehler ausgegeben aber als ganze Datei samt Pfad.

Weil ditto ein Mac-Programm ist, ich aber ein Linux-Betriebssystem kopieren musste.

Ich bin kein Linux-Kenner, aber ditto ist doch ein UNIX-Programm, das es auch unter Linux geben müsste.
Auf jeden Fall ist es kein klassisches Mac-Programm, mit GUI und aus dem Programmordner heraus zu starten.

Nope. ditto kommt von NEXTSTEP und wurde nie auf andere Unices portiert. Es erkennt das Linux-Dateisystem nicht einmal …

Ganz abgesehen davon enthielt die SD-Karte etliche Partitionen mit unterschiedlichen Dateisystemen, die ich alle hätte einzeln neu anlegen müssen, und dann jeweils von Partition zu Partition kopieren – da war eine simple Byte-Kopie viel einfacher und somit auch sicherer, um zunächst mal zu retten, was zu retten ist.

Ich habe mir mittlerweile die Umgebungen der fehlerhaften Bereiche im Hex Editor angesehen, und irgendwo mehr oder weniger nah sind dann auch immer Strings im Programmcode, aus denen man zumindest erahnen kann, um was es sich da handelt.

Aber ein „Reverse-Dateisystem“, das Dateipfade ausspuckt, wenn man Speicherbereiche eingibt, wäre schon nett.

Uh, da lag ich wohl völlig falsch.
Hab von ditto bisher immer nur in UNIX-Umgebungen gelesen.
Vielleicht einfach falsch interpretiert?

Das ganze ist abhängig vom Filesystem und von der Frage, ob zwischen Filesystem und physischem Speicher noch eine Abstraktionsschicht (z.B. lvm) eingezogen ist.

Ansonsten brauchst Du eine Übersetzung von physischen Blöcken zu Dateien. Bei EXT2/3/4 kann "debugfs" Dir die inodes zu einem Block ausgeben:
Damit hättest Du schon mal den inode, das zugehörige File findest Du dann mit "find <mountpoint> -inum <inode>" (Achtung, inodes sind device-spezifisch, also nicht eindeutig, wenn Du mehrere Filesysteme hast). Das ist ziemlich langsam, aber funktioniert.

Das entsprechende Tool für XFS ist "xfs_db", da gibt es eine Funktion "convert", die u.a. physische Disk-Adressen in inodes übersetzen kann:
Danach dann wieder "find ...-inum".

Das finde ich mal genial, wer schreibt solche Fehlermeldungen?

Ich vermute eher dass es sich hierbei um die .text Section einer ausführbaren Datei handelt - vermutlich hast du nur das Glück, diese Datei nicht zu brauchen. Wenn es nicht so viel Aufwand ist, würde ich neu installieren und dann die Konfiguration übertragen - die scheint ja in Ordnung zu sein.

Ansonsten müsstest du ein kleines Progrämmchen schreiben (RasPI? dann ginge das in Python), dass jede Datei auf der defekten SD-Karte öffnet und komplett einliest. Ein Shell-Script ginge auch oder ein Einzeiler mit "find" mit der du alle Dateien aufgelistet bekommst und diese dann nach /dev/null kopierst. So zum Beispiel:
Wenn es dabei zu Fehlern kommt, dann zeigt cp den an. Allerdings wirst du da einiges an Geduld mitbringen müssen - es sind einfach sehr viele Dateien - und du musst es mit root-Rechten ausführen. Gegebenenfalls beim RasPi auch für Kühlung sorgen...

Du könntest die installierten Dateien über den Package Manager überprüfen und Dir dann anzeigen lassen, welche Datei fehlerhaft ist.

[quote=Peter Eckel]
Das klingt verheißungsvoll. Nur leider kriege ich stets <block not found> als Antwort.

Gebe ich den Block falsch ein? In meinem eingangs zitierten Beispiel


wäre der Block doch 661392, oder sehe ich das falsch?

Welchen meinst Du denn? Ich hätte apt, aptitude und dpkg im Angebot, und bin leider mit keinem sonderlich vertraut (ich habe das System vor 8 Jahren mal aufgesetzt und seitdem nie wieder angerührt …)

Kannst Du einen Hint geben, wie ich das machen würde?

Hast Du es mal mit 661391 versucht? Linux fängt bei 0 an zu zählen.

Tritt der Fehler bei dd auf und dann wird sofort abgebrochen, oder läuft es erstmal weiter? Falls letzteres der Fall ist, liegt der Fehler gar nicht an der entsprechenden Stelle, sondern die Ausgabe betrifft die Anzahl der erfolgreich kopierten Blöcke.

Das hatte ich völlig überlesen …

Wenn ich das richtig entschlüsselt habe, stammt das aus rpc - library routines for remote procedure calls.
Äääh, wieso eher? Genau das war doch auch meine Vermutung?
Hoffe ich auch …
Davon werde ich die Finger lassen, falls es keine Probleme gibt. Das System ist nicht nur uralt, sondern läuft auch auf einem fragilen Rechnerchen mit sage und schreibe 100 MHz CPU-Takt und 64 MB RAM … Das war lange vor RasPI-Zeiten …

Da kommt dann irgendwann besser ein neuer Mini-Rechner ins Haus, aber nicht jetzt.
Das könnte man als Brute-Force-Lösung nehmen, gute Idee.
… und 100 MHz …
Gibt als Login eh nur den root-Nutzer auf dem Dingens …
Das hingegen dürfte auf meiner 100-MHz-Rakete unnötig sein …

Du verwendest eine dpkg basierte Distribution (debian, Ubuntu, Mint, …). Die wichtigste Info, die bei Deinem Posting fehlte. Es gibt auch noch rpm basierte Distributionen (RHEL, CentOS, Fedora, …) und noch einige andere Package Manager, die ich persönlich noch nie genutzt habe.
Bevor ich Dir hier länger etwas schreibe gibt es einen Link. Da hatte sich schon jemand die Mühe gemacht.

P.S. Bei dpkg basierten Distributionen empfiehlt sich für die Paketverwaltung "synaptic", das ist ein Tool mit einem GUI und erleichtert das Leben deutlich.

macOS taugt nicht mehr viel als ServerOS. Gerade wenn es um den Ersatz eines 100MHz x86 Rechners geht, dann ist eine Rapsberry Pi4 mit passiven Metallkühlergehäuse eine Rakete dagegen, verbraucht kaum Strom im Vergleich und ist absolut geräuschlos.

Na gut, aber den Block direkt daneben müsste es ja auch geben, wäre halt nicht der defekte …
Es lief weiter, da ich dd conv=sync,noerror spezifiziert hatte.
Schon klar, aber der Fehler liegt halt im ersten Block danach. Das kann ich im Hex-Editor ja auch verifizieren.

Das Problem ist glaube ich ein anderes. Ich muss ja erst das Dateisystem in debugfs öffnen. Und damit bekomme ich, falls debugfs die Blöcke relativ zur Wurzel des Dateisystems zählen sollte, natürlich für alle Partitionen außer der ersten einen Offset, den ich nicht kenne. Die erste Partition kann ich aber ohnehin nicht untersuchen, die hat ein FAT-Dateisystem.

Bei der zweiten Partition in debugfs geöffnet habe ich jetzt mit Trial & Error herausgefunden, dass Block-Werte < 184980 Inodes liefern, während mein kleinster Fehlerblock eben bereits Block 661392 ist. Oder ich muss die Blöcke doch irgendwie umrechnen?

Ja, sorry. Ich hatte das selbst nicht mehr im Kopf. Ist Debian GNU/Linux 6.0 laut Login-Shell.
Danke!
Nur, dass ich ja gar keine GUI habe auf meinem Mini-Rechnerchen.
Öhm, von Macs habe ich doch auch nie gesprochen? Klar käme da jetzt als Ersatz ein Raspberry Pi hin. Gab’s damals halt noch nicht.

Zu den Blöcken bei "dd": Wie hast Du "bs" angegeben? Wenn das nicht die Blockgröße Deines Devices ist, mußt Du umrechnen:
"dd" zählt die Records, die jeweils "bs" Bytes haben. Default sind bei mir 512 Byte (was der Blockgröße des Devices entspricht), aber darauf würde ich mich nicht verlassen.

Und ja, wenn Du eine FAT-Partition vor der eigentlichen Unix-Partition hast, dann müssen deren Blöcke natürlich auch noch abgezogen werden. Die Blockgröße und die Offsets geben Dir "fdisk" bzw. "parted" aus.

Gar nicht, sollte also die Blockgröße meines Devices sein.
Dass es 512 Bytes sind, kann ich ja einfach verifizieren, da sowohl Anzahl der Blöcke als auch die Bytes angegeben sind. Ist definitiv 512.
Mit fdisk kriege ich:
So richtig schlau werde ich daraus aber nicht.

• Was beschreiben denn die Zahlen in den Spalten Start und End?
• Sind die Zahlen in der Spalte Blocks jetzt die Partitionsgrößen oder der Startpunkt der jeweiligen Partition?
• Und was bedeutet das + hinter manchen Zahlen in der Spalte Blocks?

Ich kann da weder in sich eine Konsistenz finden noch im Vergleich zu df:

Ich war mir nicht sicher, ob "cp" die Datei auch liest, aber bei XFS sollte dem so sein. Ich hätte sonst statt "cp {} /dev/null" eben "cat {} > /dev/null" benutzt.

Ich bin mir nicht sicher, ob "mv" statt "cp" ginge... Eigentlich müssten auch da die Datei-Inhalte gelesen werden, da auf ein anderes Device geschrieben wird. Das könntest du dann gemütlich laufen lassen und Urlaub machen. Wenn du zurückkommst sind die kaputten Dateien übrig (plus diejenigen, die geöffnet waren, während das Skript lief). Alle anderen Dateien waren lesbar und löschbar und wurden auf /dev/null bewegt. OK, dort sind sie meist schwer zu finden (Frei nach Bastard Operator From Hell)

Paßt. Gut.

Ein "schönes" altes fdisk hast Du da Die alten Versionen rechnen in Zylindern, nicht in Blöcken. Funktioniert "fdisk -lu=sectors"? Oder hast Du auch parted?
1. Anfang und Ende der Partition in Zylindern (jaja, gibt's bei SD-Karten wirklich nicht mehr. Und auch sonst nicht, spätestens seit SCSI. Habe ich erwähnt, daß das ein antikes fdisk ist?)
2. Ersteres (offenbar, sonst wäre der Wert in der vierten Zeile nicht kleiner als der in der Dritten). Aber mit einer Blockgröße von 1024, warum auch immer.
3. Daß der Wert nicht stimmt

Wenn fdisk in Zylindern rechnet und die Partition in vollen Zylindern angelegt wurde, sind die Allozierungseinheiten halt Zylinder. Ein Zylinder hat bei Deiner SD-Karte 255 Köpfe * 63 Sektoren. 4 Zylinder haben also 32130 1k-Blöcke, 131 Zylinder haben 1052257.5 1k-Blöcke, und 326 Blöcke haben 2618595 1k-Blöcke. Und der Wert stimmt nun ohne Rundung, deswegen kein '+'.

Wenn Du mich jetzt fragen solltest, was die bescheuerte 'Rumrechnerei soll: Das haben sich die Autoren von fdisk inzwischen auch gefragt und nutzen Zylinder nur noch optional. Früher war das mal nötig, weil die Device Driver auch in Köpfen, Spuren und Sektoren dachten. Ganz übel wird es, wenn man dusselig genug ist, fdisk im Zylinder-Modus zu benutzen und hat vorher die Platte in Blöcken partitioniert ... damit kann man sich dann ganz toll die Partitionstabelle zerschießen.

Das paßt schon ganz gut:

• /dev/mmcblk0p1 hat in fdisk 4 Zylinder, also 64260 Blöcke. Abzüglich Overhead bleiben fürs Filesystem 64032 netto.
• /dev/mmcblk0p2 hat in fdisk 130 Zylinder, also 2088450 Blöcke. Abzüglich Overhead bleiben fürs Filesystem 2071384 netto.
• /dev/mmcblk0p3 hat in fdisk 325 Zylinder, also 5221125 Blöcke. Abzüglich Overhead bleiben fürs Filesystem 5154848 netto.

Damit sollten sich die Blockgrenzen eigentlich schon ordentlich berechnen lassen ...
... wenn die Werte aus "fdisk" stimmen sollten, wovon ich aber anhand der stimmigen Ergebnisse ausgehe.

Wo ich das gerade sehe:Es ist keine richtig gute Idee, auf eine SD-Karte zu loggen. Frag' mal Tesla

Bevor mich jetzt jemand haut: Ich habe gelogen

Das stimmt auch nicht. Die erste Partition fängt nicht in Block 0 an, da fehlt nämlich noch die Partitionstabelle. Und damit beginnt die erste Partition auch noch auf einem ganz krummen Zylinder - was die im Vergleich zum gerundeten Zylinder-Größenwert doch deutlich geringere Blockzahl erklärt.

Die erste Partition dürfte 64197 Blöcke haben. Das läßt 63 Blöcke für die Partitionstabelle, und damit landen wir jetzt hier:


Jetzt paßt es aber wirklich.

Ganz herzlichen Dank für die viele Arbeit, die Du dir gemacht hast! Das hat mir viel Schweiß erspart. Ich werde aber vermutlich erst heute Nacht dazu kommen, damit weiterzumachen.
Naja, worauf sonst? Das ist ja nun mal das einzige angeschlossene Speichermedium. Eine USB-SSD wäre ja größer und teurer als der ganze Rechner … Die ganzen Mini-Rechnerchen à la Raspberry Pi nutzen doch SD-Karten, auch zum Loggen.

Da steht auch nicht sooo viel und Wichtiges drin. Wann ich welches Licht an und ausgemacht habe und alle paar Minuten die Raumtemperaturen …

Was würde Tesla denn erzählen, würde ich fragen??

SD-Karten haben eine höchst beschränkte Anzahl an möglichen Schreibzyklen, und die üblichen Linux-Logs werden ziemlich oft geschrieben. Das paßt nicht richtig gut zusammen.

Die eine Möglichkeit (wenn Du die Logs nicht brauchst), ist nicht zu loggen. Eine andere (wenn Du die Logs manchmal brauchst, aber nicht lange) ist, dafür eine Ram-Disk zu benutzen, dann sind sie halt nach einem Reboot weg. Die dritte Möglichkeit ist sie per syslog an einen anderen Server zu schicken, der dafür besser geeignetes Storage hat.

Und Tesla hat das anscheinend auch nicht so genau gewußt ... die EMMC-Drives, die sie dafür genommen haben, sind auch nicht viel haltbarer als SDs. Das Resultat:

Die 'Lösung', einfach eine größere EMMC zu nehmen, ist übrigens selten dämlich ...

Wenn Du X11 auf dem Mac hast, kannst Du das Ding per X11 fernsteuern.
Freudscher Verleser von mir, ich las nur Mini und dachte bei Dir an einen Mac Mini.

OK, ja, soweit ist mir das ja klar.

In die Partition, die Dir aufgefallen ist, werden allerdings nur die Logs meines Hausautomationssystems (FHEM) geschrieben, und das ist nicht so viel. Die Partition ist 2,5 GB groß, das reicht ohne jegliche Rotation für hochgerechnet ca. 50 Jahre, also jedenfalls länger, als ich noch lebe. Insofern sollte das nur ein Problem sein, falls das Anhängen neuer Einträge jedes Mal ein Neuschreiben der gesamten Datei zu Folge hätte, was ich doch nicht hoffe.

Die Unix-Logdateien sind auf der Linux-Partition, das könnte ein größeres Problem werden. Fast alle I/O-Fehler jetzt waren in der Tat auch auf dieser Partition. Mal sehen, ob ich da das Logging reduzieren kann.

Ich hatte jetzt doch schon etwas Zeit zum Rumprobieren.parted habe ich nicht, aber -u bei fdisk funktioniert:

Dein Ergebnis war:
Also perfekte Übereinstimmung.

Nur leider hilft mir das nicht viel weiter, denn bei den allermeisten Fehlerblöcken gibt debugfs mit der Partitions-relativen Blockzahl nach wie vor <block not found> zurück, und wo es eine Inode zurück gibt, verweist find dann auf eine völlig heile Datei.

Ist also theoretisch genau, was ich gesucht habe, will praktisch nur aus irgendeinem Grund (noch) nicht. Grmbl. Ich forsche später weiter.

So, ich habe jetzt alles möglicher ausprobiert. Das ist wieder mal so ein Fall, wo Murphy seine vielfältigen Facetten unter Beweis stellen konnte.

Nachdem ich wie beschrieben mit debugfs nicht so recht vorankam, habe ich erstmal die anderen Methoden durchprobiert.
Prinzipieller Nachteil diese Methode ist natürlich, dass sie nur beschädigte Dateien der Systeminstallation findet und keine selbsterstellten. Da sie aber effizient klang, dachte ich, ich fange damit mal an.

Leider scheiterte ich aber schon beim allerersten Schritt der verlinkten Beschreibung; apt-get install debsums endete bei mir immer mit einer Fehlermeldung von dpkg. Da ich keine Lust auf Fehlersuche auf Metaebene hatte, habe ich es dabei erstmal belassen.

Ich habe gemäß Deinen Hinweisen find . -type f -exec cat > /dev/null \; verwendet und zunächst zu meinem Erstaunen überhaupt keine beschädigte Dateien gefunden, bis mir auffiel, dass es natürlich keinerlei Sinn ergibt, diesen Befehl über die geklonte und nun eingebaute SD-Karte laufen zu lassen. Denn da sind alle fehlerhaften Stellen ja durch Nullen oder Leerzeichen ersetzt, was den Dateiinhalt zwar unbrauchbar macht, aber natürlich beim Auslesen keine Lesefehler erzeugt.

Also musste die fehlerhafte Originalkarte wieder her, die schon im Müll gelandet war. Allerdings wollte ich sie nicht erneut in meinem Hausautomationsserver einbauen und damit die Hausteuerung erneut lahmlegen. Durchsuchen in macOS ging aber natürlich auch nicht, da macOS das Linux-Dateisystem ja nicht erkennt. Also blieb eine Ubuntu-Installation in VMware Fusion, nur dass die beim Update auf Mojave und parallel eine neue Fusion-Version leider zerschossen worden war. Also habe ich erstmal die halbe Nacht damit zugebracht, meine VMware-Maschinen zu reparieren …

Danach konnte ich dann die vorgeschlagene Brute-Force-Methode anwenden. Die funktionierte zwar prinzipiell, bei mehreren Durchläufen nach jeweils erneutem Mounten der SD-Karte stellte sich aber heraus, dass jedesmal andere Dateien Lesefehler verursachten. Der Schadzustand der SD-Karte unterliegt also leider Schwankungen, so dass sich damit wiederum nicht festellen ließ, welche Dateien beim Klonen auf die neue SD-Karte es denn nun waren, die nicht korrekt kopiert werden konnten. Da blieb wirklich nur das dd-Fehlerprotokoll mit der Angabe der defekten Blöcke, an deren Umwandlung in Dateipfade ich aber halt gescheitert bin.

Immerhin, zwei Dateien sind offenbar so korrupt, dass sie bei jedem der Testdurchläufe Lesefehler verursachten und also definitiv zerstört sind. Das waren /usr/bin/dpkg und /usr/bin/pcretest. Also ausgerechnet der Package Manager – kein Wunder folglich, dass ich mit der von gfhfkgfhfk vorgeschlagenen Methode schon beim Herunterladen des dafür fehlenden Package scheiterte …

Immerhin war das Ergebnis konsistent mit den von dd als fehlerhaft gemeldeten Blöcken, die ich mir daraufhin im Hex-Editor angesehen hatte; dass ein bestimmter Bereich zu dpkg gehörte, ist völlig plausibel und war von mir daher schon befürchtet worden.

Die einzige Methode, die mir verlässlich sagen könnte, welche Dateien bei dem konkreten Kopiervorgang auf die neue SD-Karte zerstört wurden, wäre also in der Tat die Methode, die Blöcke in debugfs auszuwerten, und ich verstehe nach wie vor nicht, warum die nicht funktioniert.

Interessanterweise weiß ich ja nun von 2 Dateien definitiv, dass sie fehlerhaft sind, und kann mir daher die Inodes ausgeben lassen:


Das ist so weit konsistent mit debugfs -b512:


Aber wenn ich nun eine Fehlermeldung aus der dd-Ausgabe hernehme wie
von der ich durch Eingabe von 447627776 im Hex-Editor definitiv bestätigen kann, dass das eine Schadstelle ist (lauter Nullen) und dass der umgebende Code definitiv zu pcretest gehört (… Usage: pcretest [options] [<input file> [<output file>]] …), dann müsste ich doch durch die Blockangabe 874273 – 64260 (Start-Offset) = 810013 in debugfs -b512 die zugehörige Inode 14577 bekommen, und das tue ich eben nicht:
Habe ich da einen Denkfehler, oder tut debugfs nicht, was es soll?


Pragmatisch kann ich das Problem jetzt auf sich beruhen lassen. Ich weiß in etwa, was zerstört wurde, und es sieht so aus, als würde mein kleiner Server noch durchhalten, bis es neue Hardware samt neuer Linux-Installation gibt.

Aber ich hätte zu gern die exakte Fehlersuche erfolgreich beenden können, um in Zukunft für ähnliche Fälle ein erprobtes Verfahren an der Hand zu haben.

Lösung

OK, ich saß auf der Leitung, jetzt hab ich’s. Bei näherer Betrachtung des Zahlenwusts in meinem vorangegangenen Beitrag fiel mir auf, dass ich die Blockangaben der Fehlermeldungen von dd durch 8 dividieren muss, um sie in debugfs verwenden zu können, warum auch immer (einmal Bits, einmal Bytes??).

Hier also für die Nachwelt der ganze Vorgang exemplarisch mit einem Fehler:

Kopie von schadhafter SD-Karte (/dev/disk8) auf neue SD-Karte (/dev/disk9), mit resultierender Fehlermeldung:


Dateisystem-Layout mit fdisk feststellen:

Der Fehler (Block 874273) tritt offenkundig in den Blöcken auf, die zu /dev/mmcblk0p2 (64260 – 2168774) gehören.

Da debugfs von /dev/mmcblk0p2 aus rechnen wird, muss der Start-Offset abgezogen werden:
Das Ergebnis wird dann durch 8 geteilt und gerundet:

Nun in debugfs das betroffene Dateisystem öffnen, mit icheck die Inode zum Block suchen und mit ncheck den Pfad zur Inode:


Voilà: /usr/bin/pcretest ist beschädigt.

Hat jemand eine Idee, warum ich die Block-Werte aus dd und fdisk durch 8 dividieren muss, um sie in debugfs verwenden zu können?

Nach der vollständigen Analyse aller in meinem konkreten Fall beschädigten Dateien kann ich bestätigen, dass das für diesen Fall zumindest definitiv stimmt, nur bin ich ja rein heuristisch darauf gestoßen und verstehe nicht, warum.

Rufe doch in debugfs bitte mal das stats-Unterkommando auf. Was steht bei Block Size?

Ahaaa – 4096 (= 8 × 512 … ).

Was ich allerdings nicht verstehe: Genau solche Inkonsistenzen befürchtend, habe ich zunächst sicherheitshalber debugfs immer als debugfs -b 512 gestartet und damit erst aufgehört, nachdem ich mehrfach überprüft hatte, dass das nichts am Verhalten gegenüber debugfs (ohne Parameter) ändert.

Ich habe jetzt gerade nochmals debugfs -b 512 gestartet, aber die Block Size-Angabe von stats bleibt auch dann bei 4096. Kann natürlich sein, dass das schlicht ein Bug ist.

Jedenfalls tausend Dank an Dich zur Aufklärung auch des letzten Stolpersteins!

Das Problem ist, daß die Allokationseinheit für das Filesystem halt (in diesem Fall, man kann das je nach Filesystem auch deutlich vergrößern) 8 Device-Blöcke sind. Deswegen mußt Du auch bei der Umrechnung immer abrunden - Du brauchst den Anfang des Filesystem-Blocks. Daran hätte ich auch denken sollen, sorry - hatte ich komplett zu erwähnen vergessen.
Nein, das ist korrekt so - debugfs rechnet, seinem Namen treu bleibend, mit Filesystem-Blöcken. Die sind nicht notwendigerweise identisch mit Device-Blöcken.
Gern geschehen.