Unterschiede ext4, xfs, zfs, btrfs bei Stromausfall

[Erich B. (Gast)]

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

:-/

[Bauform B. (bauformb)]

grep -a for the rescue!

[(prx) A. K. (prx)]

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.

[(prx) A. K. (prx)]

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.

[S. R. (svenska)]

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.)

[(prx) A. K. (prx)]

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.

[Bauform B. (bauformb)]

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.

[(prx) A. K. (prx)]

Ist eben alles eine Frage der richtigen Reihenfolge interner 
Operationen.