Aufgrund einer großzügigen Leihgabe von Herbert (nochmal besten Dank
) konnte ich in den letzten Tagen endlich einmal selbst eine zielgerichtete Testreihe durchführen, bei der sich das Problem zuverlässig (nicht nur alle Schaltjahre mal, wie bei meinem Gerät) reproduzieren ließ.Die erweiterten Erkenntnisse möchte ich hier nun ergänzend dokumentieren:
- Das Auftreten des Problems ist anscheinend unabhängig von der Gesamtgröße der Aufnahme. Wie schon vermutet, scheinbar wirklich nur die Größe des herausgeschnittenen Teilstücks ("Cut-File") ausschlaggebend zu sein.
- Auch wenn man dieses Teilstück gar nicht speichert, sondern im Schnittdialog (interne Schnittfunktion) die Option "Schneiden" wählt, erfolgt die Beschädigung des verbleibenden Rest-Files nach dem beschriebenen Muster.
- Es hat sich herausgestellt, dass die Abweichung der im Inode gespeicherten Blockzahl nicht in allen Fällen genau 2²⁰ (= 1.048.576) beträgt.
Falls das Cut-File nämlich größer als 8 GB ist, so kann der Fehler (Überlauf oder wasauchimmer) offenbar auch "doppelt" entstehen. Das heißt, die Abweichung kann in diesem Fall entweder 0 oder 1.048.576 oder 2.097.152 betragen.
Vermutlich lässt sich das verallgemeinern zu:
Wenn das Cut-File größer ist als n * 4 GB, so kann die Abweichung das 0- bis n-fache von 1.048.576 betragen.
Das Rest-File ist immer um denselben Betrag "zu groß", um den das Cut-File "zu klein" ist.
(Bis zu einer Größe von 18 GB habe ich es ausprobiert, und tatsächlich die 4-fache Abweichung erhalten.)
- Wenn beim Schneiden einer Aufnahme die Inode-Beschädigung erzeugt wurde, und man anschließend das Cut-File (welches dann laut der gespeicherten Blockzahl um 2²⁰ Blöcke, oder 4 GB, "zu klein" ist), weiter beschneidet, so kann es passieren, dass die Blockzahl dieser Aufnahme "negativ" werden müsste - was in der Folge zu einem weiteren Überlauf führt.
Ein Beispiel:- Man nehme eine Aufnahme "ZweiFilme.rec" mit Dateigröße von exakt 5 GB (= 5.368.709.120 Bytes oder 1.310.720 Blöcke).
- Man speichere den Block-Bereich 100.000 - 1.210.720 als neues Cut-File ("ErsterFilm.rec").
- Das neu erzeugte Cut-File belegt nun real 1.110.720 Blöcke auf der HDD. Durch den "Aufnahmenfresser" wird die Blockzahl im Inode aber um 2²⁰ reduziert, also beträgt diese nur 62.144.
- Nun schneidet man eine Werbepause aus der soeben erzeugten Aufnahme heraus, welche nochmals 100.000 Blöcke beträgt.
- Bei dieser Aktion wird die Größe des Cut-Files völlig korrekt bestimmt (es ist schließlich < 4 GB), und diese wird dann auch völlig korrekt von der Blockzahl der Rest-Aufnahme abgezogen. Dummerweise stimmt aber eben diese Blockzahl der Rest-Aufnahme gar nicht.
Die tatsächliche neue Blockzahl der verbleibenden Aufnahme lautet: 1.110.720 - 100.000 = 1.010.720
Der Topf rechnet aber: 62.144 - 100.000 = 536.833.056 - Und wieso jetzt 536.833.056?
Hier würde die Zahl negativ: 536.833.056 = 0x01FFF6C20 - und das ist die negative Darstellung von −37.856 (bei Zahlenlänge von 28 Bit).
Es gilt also: 0x01FFF6C20 + 2²⁰ = 0x0200F6C20
und 0x0F6C20 = 1.010.720
- Zur vereinfachten Diagnose des Problems kann ich das Kommandozeilen-Tool jfs_icheck empfehlen, welches in Zusammenarbeit mit Tino Reichart (einem der JFS-Mitentwickler) entstanden ist (danke nochmal dafür ) und auch im aktuellen MovieCutter zum Einsatz kommt.
Mit diesem lassen sich einzelne Dateien schnell und einfach auf die Beschädigung überprüfen:(Bitte beachten: Die Reparaturfunktion von icheck alleine ist nicht zuverlässig, da die "should-be" Blockzahl in manchen Fällen falsch berechnet wird!)Code: Alles auswählen
[b]Benutzung :[ /b] # jfs_icheck /dev/sda2 "/mnt/hd/DataFiles/SuspekteAufnahme.rec" [i](oder mit Inode-Nr)[/i] # jfs_icheck /dev/sda2 -i 12405 [b]Ausgabe :[ /b] jfs_icheck version 0.3b, 2014-07-10, written by T. Reichardt & C. Wuensch ??: Inode[12405]: size=4115730432 blocks=536827153, should be 1004817 (not fixed) 1 files given, 1 found. 0 of them ok, 0 were fixed.
Meine aktuellen TAPs: 
für deine analyse !!!
