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.
:
Bearbeitet durch User
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.
:
Bearbeitet durch User
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.
Ist eben alles eine Frage der richtigen Reihenfolge interner Operationen.
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.