Da fehlt so viel Kontext

[Isotopp]

*seufz*

Dateisysteme sind ein schwieriges Thema, und hier hat Golem eine Pressemeldung veröffentlicht, ohne sie zu verstehen oder auch nur auf Kontext und Plausibilität zu parsen.

Das UNIX Dateisystem ist historisch gewachsen und dann nachträglich im POSIX-Standard dokumentiert und durch den Titel "Standard" geadelt worden. Das ursprüngliche Dateisystem (Was Linux-Nutzer als "minix" kennen) wird heute nicht mehr verwendet, weil es zu viele Einschränkungen hatte, aber sein Verhalten und seine Einschränkungen sind im POSIX-Standard verewigt und fest zementiert.

Das Grundlegende Design ist gut, immerhin hat es seit 60 Jahren mitgehalten und auch in modernen Systemen seine Berechtigung.

Aber:

Es setzt ein festes Rechtesystem (ugo*rwx) und feste, endliche Listen von Dateiattributen (a/m/c time, len, permissions siehe vorher) voraus, und ist da nur schwer zu erweitern. Es gibt Erweiterungen (ACLs, xattrs), die das ein wenig verbessern, aber das ist immer noch sehr einschränkend (NTFS ACLs auf Posix mappen ist die Hölle).

Posix hat ein Konsistenzverhalten, das nur auf lokalen Dateisystemen effizient zu implementieren ist, und selbst dort nicht immer. Alle modernen Linuxe mounten zum Beispiel mit einer Variante von noatime, oder mit atime Delay (nur ein Update pro Sekunde). Aber auch die Dateigröße in Byte muß zwingend live aktualisiert werden (jeder Write ist auch ein Inode Update!) und das ist in Verteilten Systemen ein replizierter Write auf Datenservern _und_ ein zwingender replizierter Write auf den Metadata-Servern - aber während sich die Datawrites auf x Kisten verteilen, ist das systembedingt bei Metadata-Servern so nicht drin.

Posix verlangt auch, daß Writes atomar sind. Wenn Du also drei MB von Offset 0 beschreibst und jemand anders zeitgleich drei MB von Offset 1 MB schreibt, dann muß Dein Write entweder ganz vor oder nach dem anderen Write kommen - die Writes müssen also Locken. Alle Dateisysteme (mit ganz wenigen Ausnahmen) in Linux machen das mit einem globalen Lock auf der in-memory Inode, sodaß nur ein Write zur Zeit auf der ganzen Datei stattfinden kannst. Wenn Du also eine 17 TB Datenbank-Datei im Dateisystem hast, dann passiert da nur ein Write zur Zeit und Du hast Contention auf der Inode. Ausnahme ist XFS, wenn die Datei O_DIRECT geöffnet ist, dann macht XFS intern still und heimlich Range-Locking. Datenbanken wie Oracle teilen Dateien deswegen in Tablespace-Files (.DBF-Dateien) von ca. 1-4 GB Größe auf. Dann hat die jede Datei so ein Lock, aber der Tablespace hat viele Locks und wenig Contention.

Auf verteilten Systemen ist so ein Lockverhalten nur durch Verteiltes Locking zu implementieren, also 2PC (Two Phase Commit) oder schlechter, ein Write ist daher immer 2 Round Trip Times oder langsamer. Write, wohlgemerkt schon, nicht commit (fsync), wegen der o.a. Posix-Bedingung.

Dazu kommt natürlich der Oberkiller: Da Files mutable sind, können Daten überschrieben werden. Du kannst also in einem 10 MB File ein MB ab Offset 3 MB überschreiben. Das bedeutet, daß alle Caches im ganzen System invalidiert werden müssen. Das bedeutet, daß jeder Cache Entry zentral geloggt und beim Überschreiben notifiziert werden muß - synchron!, und das bedeutet, daß Du das 2PC mit am Ende allen Nodes in Deinem Cluster machen mußt. Das ist korrekt nicht effizient implementierbar und daher bescheißen alle Systeme dabei.

Wir halten fest:
- Synchrone Metadata Updates
- Limitiertes Vokabular bei Metadaten
- Writes sind 2PC locking und daher langsam.
- Write Caches und Mutable Files sind der Clustertod.

Beachte auch, daß das alles Lower File System Probleme sind, also auf Datei-Ebene. Probleme auf Upper File System, also bei der Aufbau und Strukturierung des Namensraumes gibt es auch noch, aber solange Lower File System nicht skaliert braucht man da gar nicht anfangen.

Object Storages umgehen einige dieser Probleme:
- Files sind Immutable, bestenfalls Append Only
- Append Only ist Eventually Consistent.
- Am File hängt eine KV-Tabelle von Attributen, die echt richtig groß werden können.
- Attributupdates sind Eventually Consistent.
- Metadata ist Eventually Consistent (ja, wir können eventuell über die Länge lügen)

Der größte Helfer ist die Immutabilität, denn sie bewirkt, daß wir nun jeden Scheiß gefahrlos cachen können. Er ermöglicht auch die ganze Eventual Consistency, und damit sind wir die ganzen 2PC Waitgeneratoren los.

Und den Upper Filesystem Kram hat man sich dann komplett geschenkt und stattdessen einen KV-Store implementiert, bei dem die Keys wie Pfadnamen aussehen und die Values die Dateien sind.

Und dann können wir mal darüber reden, wieso Log Structured Merge Trees bei Datenbanken plötzlich so populär geworden sind und wie das mit Object Storages zusammen spielt. Oder warum Fowler Event Sourcing und CRDT aufbringt, und wie das mit Object Storages zusammen spielt.

Unix System V Filesystem ist Tech von 1974, BSD FFS ("ext2") ist Tech von 1984, XFS ist Tech von 1994, ZFS, BTRFS und WAFL sind auf LFS basierende Tech von 2004, und Tech von 2014 sind LSM, Object Storages, "RocksDB" und leider auch ein Haufen Bitcoin Bros, die das alles falsch verstanden haben.

[MarcusK]

danke für die Infos - das macht dann schon deutlich mehr sinn.

Mich wundert das Linux (noch) so ein locking hat. Windows bieten schon immer ein Rangelock auf Dateien an. Dort ist es kein Problem mit mehreren Prozessen/Threads in eine Datei zu schreiben. Selbst übers Netzwerk.

[Isotopp]

Windows Rangelocks lösen ein ganz anderes Problem als das POSIX Inode Lock, und für diesen Anwendungsfall hat Posix die deutlich besser Lösung.

[the_crow]

Danke, für die ausführliche Erklärung und Einordnung, die hätte ich mir im Artikel gewünscht!