Also UFS verwendet soft-updates statt metadata journaling und kein data journaling. Manche Dateisysteme verwenden data und metadata journaling. Diese Dateisysteme verhalten sich anders für Anwendungen, die beschissen mit ihren Dateien umgehen und kein fsync() verwenden sondern sich auf Eigenheiten von z.B. ext3 verlassen. Diese Anwendungen können dann wunderbar explodieren, wenn sie mit einem anderen Dateisystem konfrontiert werden.
Die soft-updates des UFS sind genau an der Grenze dessen was Festplatten behaupten zu können. Sie verlassen sich darauf das ein write der als auf stable memory gemeldet wird auch wirklich auf stable memory ist. Billige Platten an normalen Controllern sehen das nicht so eng. Besonders Laptopplatten lassen sich oft beim Lügen erwischen. Das Ergebnis ist ein beschädigtes UFS, das ein fsck braucht. Nicht lustig, aber meistens kein Weltuntergang.
Mit guten Platten an nem ordentlichen HW RAID Controller mit BBU wirst du keines dieser Probleme haben. Der Controller bietet einen zuverlässigen write back Cache. Damit kannst du guten Gewissens UFS mit 6TB verwenden, wenn du es willst.
Problematisch an UFS ist das es nach einem Stromausfall oder einer Panic ein background fsck braucht. Dieses braucht trotz aller Optimierungen bei 6TB auf wenigen Platten mehrere Stunden. In dieser Zeit wird fsck langsam immer mehr RAM fressen (so 500MiB bis 1GiB pro 1TiB) und relativ viel IOPS belegen.
Die Lösung dafür ist ab FreeBSD 9.0 journaled soft-updates. Hierbei wird ein kleines Journal geführt in dem nur Allokationen vorgemerkt werden. Mit diesem Journal kann fsck in wenigen Sekunden potentielle Speicherlecks beheben, die soft-updates als einzigen Fehler zulassen. Der Nachteil an den journaled soft-update ist, dass sie sich nicht zeitgleich mit UFS Snapshots verwenden lassen. Damit verliert man die Möglichkeit Backups von r/w gemounteten UFS Dateisystemen per dump -L anzufertigen.
Kommen wir zu ZFS. Damit ZFS seine Selbstheilung durchführen kann musst du ihm die Platten als JBOD durch reichen. Über den write Cache des Controller freut sich ZFS genauso wie jedes andere Dateisystem solange der Controller nen Cache flush auf den Devices als einen in seinen write Cache übersetzt und nicht dumm weiterreicht an die Platten. Bei ZFS ist man meistens besser damit bedient statt eines HW RAID Controllers für das Geld SAS HBA und zwei kleine SSDs zu kaufen.
ZFS benötigt deutlich mehr RAM als UFS, aber damit erkauft man sich vieles.
- Checksums über Daten und Metadaten gegen Bitrot
- Snapshots und Clones
- Speicherverwaltung in Pools statt Dateisystemen
- Replikation mittels Snapshots
- ...
Fazit: ZFS macht das Leben des Admins bequemer und ruhiger.
