Re: Welches Filesystem für Heimserver (weg von XFS?)?
Am Freitag, 30. Dezember 2011 schrieb Dirk Salva:
> Bisher nutze ich XFS, bin damit aber nicht so ganz zufrieden, weil man
> nach einem Hänger (Freeze, Kernel-Oops oder sowas, ansonsten läuft die
> Kiste an einer USV) immer ein sehr umfangreiches xfs_check und
> xfs_repair mit Hilfes eines Bootsystem fahren muss, und
> ärgerlicherweise bisher auch jedesmal so gut wie alle geöffneten files
> (einmal wars sogar logrotate, was zu erheblicher Verwirrung im System
> geführt hat) verlorengegangen sind. Gibt es da eine Weiterentwicklung,
> bei der nicht so viel verlorengeht bzw. das Risiko geringer ist? Oder
> ist das Problem schlicht unlösbar?
XFS sollte nach einem plötzlichen Schreibvorgang immer automatisch durch
das Rückspielen des Journals wieder hochkommen - es ist genauso ein
Journal-basiertes Dateisystem wie Ext4. Ein Dateisystem-Check ist - es sei
denn die Hardware produziert Bitfehler - in der Regel nicht erforderlich.
Die XFS-Entwickler sind sich dessen sogar sehr sicher, wie ein Blick in
fsck.xfs zeigt.
Durch das kompaktere, teilweise logisch aufgebaute Journal - ändere in
diesem Block das und das -, gegenüber dem blockbasierten Journal von Ext4,
können bei einem Crash jedoch mehr Daten verloren gehen.
Ein weiteres Thema ist Delayed Allocation. Das machte XFS schon immer,
Ext4 macht es auch. Delayed Allocation bedeutet verzögertes Belegen von
neuen Blöcken, was dazu führen kann, dass eine Datei, die gleich wieder
gelöscht wird, gar nicht erst auf Platte geschrieben ist.
Dummerweise kann das auch schiefgehen, wenn die Anwendung nicht mit
fsync() arbeitet. Da gibt es im Wesentlichen zwei Fälle:
1) Die Anwendung schreibt eine neue Datei und benennt diese dann auf die
alte Datei um. Dabei kann passieren, dass die neue Datei noch gar nicht
geschrieben ist, aber das Umbenennen schon stattgefunden hat => Null-Byte-
Datei. Ext4 hat auf Drängen unter anderem von Linus ab 2.6.30 einen Work-
Around und macht dann genau in diesem Fall eben kein verzögertes Belegen.
XFS hat da meines Wissens keinen Workaround zu.
2) Truncate, also Dateien kürzen. Auch hier kann die Reihenfolge
durcheinander kommen, was zu einer inkonsistenten Datei führt. Den genauen
Ablauf dazu habe ich gerade nicht im Kopf. XFS und Ext4 ab 2.6.30 sollten
diesen Fall abfangen und dann ebenfalls sofort schreiben.
Obwohl Ext4 für den Umbenennen-Fall einen Work-Around haben sollte, hatte
ich es einmal bei einem plötzlichen Abbruch, ich glaube, es war ein
Kernel-Crash, beim Starten von KDE 4, dass viele Konfigurationsdateien von
KDE 4 Null-Byte lang waren. KDE 4 hatte eine Zeit lang den Fehler, dass es
beim Starten sämtliche Konfigurationsdateien über die Umbennen-Art neu
geschrieben hat. Seit diesem Vorfall habe ich ein rdiff-backup davon.
KDE verwendete mal fsync(), aber in Ext3 mit data=ordered, war das und ist
es vielleicht noch aber ziemlich langsam. Und dann haben sie es halt
abgeschaltet. Es ist möglich, das über eine Umgebungsvariable wieder
einzuschalten:
martin@merkaba:~> grep -A3 "KDE Sync" .zshrc
# KDE Sync
# http://oss.sgi.com/pipermail/xfs/2009-March/040628.html
export KDE_EXTRA_FSYNC=1
Seitdem hatte ich mit Ext4 als /home kein Thema mehr.
Aber eigentlich sollte es in Ext4 auch so funktionieren.
Meine Gesamterfahrung ist, dass XFS etwas anfälliger ist, wenn die
Hardware Ausfälle hat. Aber einen xfs_repair musste ich bei abruptem
Abbruch der Schreibvorgänge eigentlich auch in meinen XFS-Zeiten dann
schon ewig nicht mehr fahren.
Weiterer Vorteil von Ext4, den die XFS-Entwickler mittlerweile durch
teilweise gravierende Optimierungen relativierten: Höhere Performance beim
Umgang mit Metadaten. Eines der krassesten Beispiele tar -xf
linux-3.2.tar.gz und dann rm -r auf die ausgepackten Quelltexte. Machen
Server-Dienste allerdings jetzt in der Regel auch nicht ständig. Und wenn
in Dateien rumgeschrieben wird, fällt XFS schon durch sehr gut
skalierende, ausgeglichene Performance auf.
So oder so, wenn Du SSDs einsetzen möchtest, empfehle ich Dir mindestens
Kernel 3.0. Für Batched Discard.
Ansonsten empfehle ich Dir, Dir die Antworten auf die Fragen
23 Q: Why do I see binary NULLS in some files after recovery when I
unplugged the power?
24 Q: What is the problem with the write cache on journaled filesystems?
25 Q: How can I tell if I have the disk write cache enabled?
26 Q: How can I address the problem with the disk write cache?
26.1 Disabling the disk write back cache.
26.2 Using an external log.
26.3 Write barrier support.
27 Q. Should barriers be enabled with storage which has a persistent write
cache?
in der XFS-FAQ mal reinzuziehen¹.
[1] http://xfs.org/index.php/XFS_FAQ
Ciao,
--
Martin 'Helios' Steigerwald - http://www.Lichtvoll.de
GPG: 03B0 0D6C 0040 0710 4AFA B82F 991B EAAC A599 84C7
Reply to: