Re: fehlerhafte Sektoren im chkdsk log

Hallo!

Shinji Ikari schrieb:
>> Ein Bluescreen im falschen Moment, und das gesamte
>> Filesystem ist über den Jordan.
>
> Ein simpler (ueberschreibender) Virus und die Daten eines JFS
> verwalteten Datentraegers sind ebenfalls nicht mehr wichtig. 8)

Das ist korrekt. Das tückische an FAT32 sind allerdings die latenten
Fehler durch inkonsistenzen in der FAT. Dadurch kann es dazu kommen,
dass in einer augenscheinlich korrekten und lesbaren Datei einzelne
Blöcke aus anderen Dateien enthalten sind. das bemerkt man genau dann,
wenn sich ein Programm oder ein Anwender darüber beschwert. Das kann bei
seltener benötigten Daten Jahre dauern. Zu dem Zeitpunkt sind dann
möglicherweise auch mehrfach redundante Backups nicht mehr vorhanden.
Und selbst wenn, dann ist dem Fehler in keiner Weise anzusehen, auf ein
wie altes Backup man zurückgreifen muss. Die Datei ist auf allen Backups
nominell identisch enthalten, nur die Daten sind andere.

Eine besonders tückische Variante davon sind Cross-Links in der FAT. Das
fiese an denen ist, dass sie wie ein Schwelbrand immer weiter brennen,
solange bis ein Checkdisk weiteren Schaden verhindert. Bereits ein
einziges übergangenes oder abgebrochenes Checkdisk, kann solche
unbemerkt hinterlassen. Dabei sind üblicherweise je zwei Dateien
beteiligt. Eine ist defekt und eine erstmal noch ganz. Bemerkt man die
defekte Datei und löscht sie, zerstört man die Ganze. Wird der nun
freigegebene Speicher von einer weiteren Datei belegt, ist die neue
Datei die nun Ganze und die gerade zerstörte die defekte und das Spiel
beginnt von vorne.
Auch diese Fehler sind außerordentlich fies, da sie beim Backup erstmal
nicht auffallen. Zudem gibt es keine sonderlich praktikable Handhabe,
die bei einem Dateisystem-Check beim Start als Cross-Linked erkannten
Dateien zu restaurieren. Die Information scrollt ungesehen über den
Bildschirm, die Dateien sind noch auf der Platte und niemend leitet für
jede der Dateien ein Restore aus dem Backup ein. Und selbst wenn, weiß
man wieder nicht, auf ein wie altes Backup man zurückgreifen muss, um
die korrekte Datei zu bekommen.

Es gibt auch andere latente Fehler, wie beispielsweise defekte Sektoren.
Allerdings fallen die spätestens beim nächsten Vollbackup auf, und damit
weiß man, dass man auf das Vorgängerbackup zurückgreifen muss, um die
Datei wiederherzustellen. Das ist in meinen Augen nicht einmal halb so
schlimm. Erkennbare Fehler kann man mit einem Backup kompensieren. Nicht
erkennbare nicht unbedingt.

Alles in allem sind das beträchtliche Risiken für unbemerkte Fehler. Und
das ist das Problem. Dabei ist im übrigen wenig entscheidend, dass FAT
kein Journal hat. FAT hat einfach zu wenig Redundanz im Dateisystem, um
solche Probleme zeitnah und halbwegs zielsicher zu erkennen. Andere
nichttransaktionale Dateisysteme wie IBMs HPFS oder auch EXT2 haben
längst nicht so gravierende Risiken, selbst bei übelsten Systemabstürzen
unter heftiger I/O-Last. Im Gegenteil, die sind weitgehend 'solid as rock'.
Das Journal hat andere Vorteile. Beispielsweise dauert ein Diskcheck bei
einer Million Files ein bis zwei Zehnerpotenzen weniger lang und es
können bestimmte Garantieen bezüglich der Datenkonsistenz nach
Systemabstürzen gemacht werden.


Marcel
[ Auf dieses Posting antworten ]