Also, da ich beruflich jede Menge FreeBSD-Systeme unter meiner Fuchtel habe, kann ich da in gewisser Weise aus Erfahrung sprechen. Allerdings nicht zu HAMMER, da wir hier ein reiner FreeBSD-Laden sind und es daher nicht einsetzen können. Wir haben allerdings von Kollegen übernommene Linux-Boxen im Einsatz und damit auch deren Dateisysteme:
1. UFS und UFS2 sind recht eindeutig die stabilsten und zuverlässigsten aller Dateisysteme hier. Das ist natürlich auch irgendwo ihrem sehr simplen Aufbau geschuldet. Wir hatten mit UFS schon wirklich jeden Mist, den man sich vorstellen kann, mehr als mal ein oder zwei Dateien verloren haben wir niemals. Und bisher konnte auch jedes Dateisystem wieder repariert werden, auch wenn dazu teilweise >5 fsck-Läufe notwenig waren... Im Einzelnen hatten wir:
- Über mehrere Wochen defekte S-ATA Kabel, der Kunde wunderte sich, wieso die Kiste immer abschmierte. Das Dateisystem war sehr defekt, Datenverlust trat nur auf wo eine Datei andere überschrieben hat, da die entsprechenden ATA-Kommandos zerdeppert wurden.
- gmirror-Wiederherstellung. Platte A synchronisiert auf B, sie liefen zuvor mehrere Tage asynchron. System schmiert dabei wieder ab, da Platte A defekt ist. Kollege ersetzt ohne nachzudenken Platte A, nun synchronisiert B auf A. In der Folge war der Mirror ca. zur Hälfte neu und zur Hälfte alt. Mehrere fsck-Läufe später war das Dateisystem wieder heil, alle nich synchronisierten Daten waren noch da.
Vielleicht versteht man jetzt, wieso ich nach wie vor ein großer Fan von UFS bin.
2. ZFS. Schwer dazu nun der Weisheit letzten Schluss zu ziehen, denn wir setzen es noch nicht sehr lange ein. Aber bisher hatten wir auch auf Systemen mit sehr hoher Last keinerlei Abstürze und wir hatten auch noch keine kaputten Pools und keinen Datenverlust. Dazu muss man auch sagen, dass viele der ZFS-Horrorgeschichten (mein Pool ist im Eimer, die Kiste schmiert ständig ab) größtenteils ihren Ursprung in Zeiten haben, wo einige Idioten es trotz groß sichtbaren "experimental"-Hinweis schon produktiv einsetzen mussten. Einen Nachteil hat ZFS allerdings. Als COW-Dateisystem fragmentiert es recht stark.
3. Linux-Dateisysteme. Mit Linux verbindet mich etwas Hass, da ich dem Ding diverse Nachtschichten zu verdanken habe. Das liegt nicht unbedingt am Kernel selbst, stattdessen an schnoddrigen Distributionen und unfähigen Admins, aber ich neige zu Verallgemeinerungen... Allgemein sind meine Erfahrungen mit den >30 Linuxdateisystemen sehr durchwachsen. Viele produktiv einsetzbare würden unter FreeBSD noch immer mindestens als "experimental" segeln, einige sicher sogar als "unsupported". Größere Erfahrungswerte habe ich mit:
- XFS. Kenne ich noch aus meiner Irix-Zeit. Dort hieß Crash immer gleich Backup holen. Das ist unter Linux wesentlich besser geworden, sicher auch durch Write Barriers. Allerdings stehe ich nach wie vor auf dem Standpunkt, dass XFS im Katastrophenfall unschön ist. Die Wahrscheinlichkeit, dass der B-Baum implodiert ist sicher noch immer ~10% und wenn es passiert, ist alles verloren. Dann hilft nur noch mkfs. Kann man einsetzen, ist sehr schnell, sollte aber tunlichst nur mit USV passieren.
- Ext3. Alle Ext sind UFS-Klone, die allerdings einiges an Magie einsparen. Ich habe Ext3 immer als grottenlahm erlebt, ist aber zugeben doch recht zuverlässig. Wenn wirklich mal alle Stricke reißen, kann man oft zumindest noch die Daten runterziehen.
- JFS. IMO von allen Linux-Dateisystemen der beste Kompromiss aus Stabilität und Geschwindigkeit. Hatte ich sehr wenig Ärger damit, hat sich als sehr Katastrophenresistent gezeigt. Ich frage mich, wieso es sich nie weiter durchgesetzt hat.
- btrfs. Ich bin da noch gespannt. Es wurde imo für ein so komplexes Dateisystem viel zu früh als stabil deklariert, sicher aus unter Druck der Entwickler und erster Nutzer wie Intel. Muss man mal sehen. Wenn ich meine Abneigung gegen streng baumbasierte Dateisysteme mal einen Moment vergesse, schaut es konzeptionell recht gut aus. Das einige Kollegen aber meinen es schon im großen Stil nutzen zu müssen, ist in meinen Augen idiotisch.
