Sync-Fehler bei der Restauration aus cloop-Image

[tschmitt]

Auf manchen Systemen (Windows FAT32) treten bei der Synchronisation Lesefehler auf, die u.U. ein unbrauchbares Dateisystem hinterlassen:

rsync: read errors mapping "/cloop/windows/WindowsUpdate.log": Input/output error (5)

Die Synchronisation mit "Neu+Start" klappt dagegen fehlerfrei.

[tschmitt]

Ich habe hier ein cloop-Image, da ist u.a. die Windows-Registry-Datei C:\windows\system32\config\system betroffen. Sync+Start hinterlässt eine kaputte Registry und führt daher beim Windows-Start zu einem Bluescreen. Im Log findet sich og. Fehlermeldung ("rsync: read errors mapping ..."). Neu+Start restauriert die Registry korrekt.

Startet man LINBO auf dem Client im Debug-Modus, mountet Windowspartition und cloop-Image und vergleicht die beiden Versionen der betroffenen Datei, dann fallen zunächst unterschiedliche Dateigrößen auf.

Festplatte:
4456448 /mnt/windows/system32/config/system

cloop-Image:
4194304 /cloop/windows/system32/config/system

Die Datei lässt sich auch nicht aus dem Image herauskopieren:
# cp /cloop/windows/system32/config/system /cache
cp: read error: Imput/output error
# rsync /cloop/windows/system32/config/system /cache/system
rsync: read errors mapping "/cloop/windows/system32/config/system": Input/output error (5)

[tschmitt]

Mit folgender Prozedur konnte das fehlerhafte Image "reparieren":

1. Restauration des WinXP-Systems mit "Neu+Start".
2. Nachdem Windows erfolgreich gestartet ist, nicht anmelden sondern neustarten.
3. Wieder in LINBO ein neues cloop-Image erstellen.
4. Anschließender "Sync+Start" klappt fehlerfrei.

[tschmitt]

Og. Vorgehensweise klappte auf einem anderen Rechner mit demselben Image leider nicht.

Daraufhin habe ich auf C: ein bisschen aufgeräumt: einige überflüssige Treiberinstallationsordner und temporäre Verzeichnisse gelöscht sowie ein Paar nicht benutzte Programme deinstalliert (von 11GB schrumpfte der belegte Platz auf 8GB).
Danach ein neues cloop-Image erstellt. Beim anschließenden "Sync+Start" war der Fehler verschwunden.

[tschmitt]

Scheint ein Bug im cloop-Modul gewesen zu sein. Knopper hat das in  cloop 2.6.29-1 gefixt.

[tschmitt]

Kommentar von Klaus Knopper dazu:
Das cloop-Image ist NICHT kaputt, sondern absolut in Ordnung. Was nicht in
Ordnung ist, ist die kernel-Library-Funktion kernel_read(), da diese im
gegensatz zu vfs_read() nur 32-bit Dateioffsets verarbeitet.
Erstaunlicherweise schafft sie trotzdem statt 4GB großen Dateien 8GB,
aber danach ist Schluss, und uint_32 sorgt dafür, dass jeder darüber
hinausgehende Lesevorgang wieder am Anfang der Datei landet, ohne dass
ein Fehler-Returncode darauf hindeutet, denn alle read-Aufrufe klappen
einwandfrei. Nur werden die Daten von einem falschen Offset in der
Eingabedatei geholt, und lassen sich, da der gzip-Header fehlt, nicht
dekomprimieren, d.h. den Fehler schmeißt letztendlich der Dekompressor,
obwohl der gar nichts dafür kann.
Wirkung: Alle cloop-Dateien größer als (knappe) 8GB lassen sich im
Dateisync-Modus nicht komplett lesen, bzw. genauer, die Dateien in den
darüberhinausgehenden Sektoren lassen sich nach Mount nicht lesen. Der
Partitions-Dekompressor extract_compressed_fs ist davon nicht betroffen,
sondern packt das Image brav und einwandfrei aus, was Du ja auch schon
festgestellt hast.

Lösung: kernel_read() entfernt, stattdessen vfs_read() mit dem dazu
notwendigen Wechsel in den user-address-space und wieder zurück, was
kernel_read() intern zwar auch machte, aber eben nur mit 32bit.
compressed_loop.c ist entsprechend aktualisiert. Damit schaffen wir
jetzt Eingabedateien mit 2⁶⁴ Bytes, das sind, ähm, ... VIELE Terabytes,
die wir so schnell mit handelsüblichen Platten nicht erreichen werden.

[tschmitt]

Ein weiterer LINBO-Bug ist gefixt. :-)