A. K. schrieb:> Die heute in PCs und Servern eingesetzten Filesysteme sind recht gut> darauf eingerichtet, einen Stromausfall zu überleben, ohne> Inkonsistenzen zu produzieren. Das gilt sowohl für das in Windows> übliche NTFS, als auch für die in Linux und Unix verbreiteten> Filesysteme ext4, xfs, zfs, btrfs.
Gibt es da nennenswerte Unterschiede?
Hier hat ein RCD/FI dem Serverchen den Saft abgedreht und am gerade
offenen log-File(ASCII) waren nach dem Reboot ~1500 0x00 Bytes
angehängt.
Ist ja eigentlich nicht schlimm, nur meinte dann ein grep (via cron) nur
noch:
Binary file matches
:-/
Man muss zwischen den Metadaten des Filesystems und den Inhalten von
Files unterscheiden. Alle diese Filesysteme versuchen, die Metadaten zu
schützen. Das bedeutet, dass keine Filesystem-Nodes belegt sind, ohne
dass es dafür mindestens einen Directory-Eintrag gibt. Dass Blöcke nicht
doppelt belegt sind, oder mit dem falschen File assoziiert. Sowas in
dieser Art.
Dieser Schutz der Metadaten bedeutet nicht, dass Anwendungsdaten so
aussehen, wie man sie gerne hätte. Und um die geht es hier, nämlich um
Logdaten eines Files.
CoW Filesysteme wie ZFS und btrfs unterscheiden sich von den anderen
durch die Arbeitsweise. Es werden zu keinem Zeitpunkt bestehende Daten
überschrieben. Keine Metadaten und keine Filedaten. Statt dessen werden
sie in freie Blöcke geschrieben, auch die Metadaten dazu werden ohne
überschreiben der alten Metadaten angepasst. Ab und zu wird die
Root-Information des neuen Stands auf Disk geschrieben. Erst wenn das
erfolgt ist, ist dieser neue Stand persistent. Ein Crash davor führt
automatisch dazu, dass nach dem Neustart der vorherige Stand verwendet
wird.
Überdies schützen manche neuen Filesysteme Metadaten wie evtl auch
Filedaten durch Prüfsummen, da man heute den entsprechenden Mechanismen
der Hardware nicht mehr über den Weg traut.
Eine optionale Arbeitsweise von Disks, aber auch von RAID Controllern,
kann zum beschriebenen Problem führen. Disks enthalten Puffer für zu
schreibende Daten. Wird eine Disk so betrieben, dass ein Schreibvorgang
von ihr bereits als erfolgreich bestätigt wird, noch bevor der Vorgang
wirklich stattfand, kann das Filesystem keine Konsistenz garantieren.
Allerdings ist diese Arbeitsweise deutlich schneller.
Die hier möglicherweise aufgetretene Inkonsistenz: Die in den Metadaten
des Files gespeicherte Länge passt nicht zum Umfang der tatsächlich
geschriebenen Daten. Ob oder wann das bei traditionellen Filesystemen
offiziell geschehen kann, habe ich nicht im Überblick. Bei
CoW-Filesystemen kann das nicht vorkommen. Abgesehen vom im vorigen
Absatz skizzierten Problem, und natürlich abgesehen vom Unterschied
zwischen Theorie und Praxis.
PS: CoW = Copy on Write.
A. K. schrieb:> Eine optionale Arbeitsweise von Disks, aber auch von> RAID Controllern, kann zum beschriebenen Problem führen.
Es gibt auch einige Speichermedien, die ihr Caching aus Gründen der
Performance schlicht falsch implementieren, z.B. indem ein flush()
schlicht nichts tut. Bei Speicherkarten fällt das gelegentlich auf, weil
sich moderne Dateisysteme (kein FAT) bei Ausfällen komplett zerlegen.
Das fällt aber wahrscheinlich unter "kaputte Hardware", da kann die
Software auch nicht mehr besonders viel machen.
(Erinnert mich an einen alten Vortrag zu Barcodes, wo der Vortragende
erzählte, dass die antiken DOS-basierten Systeme, die auf relativ
unzuverlässiger Hardware beruhten, ihre Eingaben wesentlich strenger auf
Sinn prüften als die moderneren Systeme mit besseren Barcode-Lesern.)
Bei Flash-Medien kann noch ein weiterer Effekt auftreten, also bei µSDs,
USB-Sticks und SSDs. Multilevel-Flash speichert ja mehrere Bits in einer
Zelle. Allerdings ist es wesentlich schneller, nur ein Bit drin zu
speichern. Weshalb das Medium u.U. erst einmal das ganze Flash mit einem
Bit pro Zelle vollschreibt, bevor es daran geht, zu bestehenden Altdaten
noch weitere Bits völlig anderer Daten hinzuzufügen. (*)
Dieses Verfahren führt dazu, dass die Bits in einer Zelle von völlig
unterschiedlichen Files völlig unterschiedlichen Alters stammen können.
Ein Stromausfall zum falschen Zeitpunkt kann dann ggf dazu führen, dass
nicht nur die neuen Daten nicht drauf sind, sondern auch die alten Daten
verschütt gingen. Manche SSD-Serien mancher Hersteller stellen sicher,
dass dies nicht vorkommt.
*: Wenn der Benchmark mit einer leeren Disk anfängt und schon aufhört,
bevor dieser Singlelevel-Betrieb am Ende ist, hat der Hersteller
gewonnen.
A. K. schrieb:> Weshalb das Medium u.U. erst einmal das ganze Flash mit einem> Bit pro Zelle vollschreibt, bevor es daran geht, zu bestehenden> Altdaten noch weitere Bits völlig anderer Daten hinzuzufügen.> Ein Stromausfall zum falschen Zeitpunkt kann dann ggf dazu führen, dass> nicht nur die neuen Daten nicht drauf sind, sondern auch die alten Daten> verschütt gingen.
Etwas ähnliches kann doch sogar mit SLC-Flash passieren, weil immer
ziemlich große Blöcke am Stück gelöscht werden müssen, z.B. 4MB, während
das Dateisystem z.B. nur 4kB-Blöcke kennt. So können auch Daten aus
einer anderen Partition verloren gehen.
