XFS oder JFS für produktiven Server geeignet?

[andreask2]

Hallo!

Im letzten Linux-Magazin gab es ja mehrere Artikel zu den verschiedenen Dateisystemen.

Mich würde mal Eure Meinung und Erfahrung interessieren, in wieweit die Dateisysteme für einen produktiven Einsatz geeignet sind, für einen Server, auf dem ein Datenbank-Server die meisten Interaktionen mit dem Dateisystem führt. Hierbei wird deutlich mehr gelesen als geschrieben, und die Daten-Dateien sind unterschiedlich groß, von einigen KB bis mehreren 100MB. Als Kernel kommt vorerst noch 2.4 mit grsec-patch zum Einsatz.

Mir geht es darum - ob es sich überhaupt lohnt von ext3 wegzugehen, das konnte mir der besagte Aurtikel nicht wirklich beantworten, denn die Benchmarks da fand ich nicht besonders aussagekräftig - zumindest nicht für mich. Das liegt vor allem daran, dass ext3 nicht mit den Standardeinstellungen verwendet wurde, uns in dem verwendeten Modus wohl _extrem_ langsam wurde zum Teil - hätte mich mal sehr der Unterschied zu den Standardeinstellungen interessiert, wie es die meisten Leute vermutlich verwenden.

Was ich noch wenig hilfreich fand war die Größe der Dateien, nicht jeder hat nur mehrere GB große Dateien auf dem Server die ständig gelesen/beschrieben werden ;-)

Was ich so da rausgelesen habe ist - dass sich die Dateisysteme in den Bereichen die ich angegeben habe (<500MB) nicht sonderlich viel tun, oder?

Der große Vorteil von ext3 ist wohl die immer noch bessere Zuverlässigkeit - oder? Wie ich das verstanden habe holen alle im Titel genannten Filesysteme Performance unter anderem aus der erheblich performanteren Implementierung des "Virtual Fielsystem Switch" (VFS), und zwar benutzen diese b-trees, ext3 dagegen ist auf Inode-basierte Dateisysteme ausgelegt. Problem an der Sache, wenn in den b-trees nur ein Fehler auftritt, kann das zu Datenverluste führen.

Leider kann ich dessen praktische Auswirkung nicht wirklich abschätzen. Ich meine - wenn die Gefahr hier wirklich groß wäre, müssten sich IBM & Co. nicht wirklich die Arbeit machen so ein Dateisystem mit einem "bekannten Design-Fehler"(nicht wörtlich nehmen) zu programmieren.

ReiserFS würde ich mal ausschließen wollen, weil man da auch heute noch von Leuten hört die da hin und wieder Ã?rger mit haben. Außerdem ist es ja wohl auf sehr kleine Dateien optimiert.

Blieben noch XFS und JFS. Beides kommt von "renomierten Herstellern", und die beide belegen auch die vorderen Plätze bei den Benchmarks im Artikel. Am Ende hat JFS gewonnen, aber das hielt der Autor noch nicht reif für den produktiven Einsatz - aber nur aufgrund fehlender Tools und Optionen. Auf der anderen Seite - IMHO gibt es die wichtigsten Tools, und so viel mache ich damit eh nicht, ich mache automatisiert inkrementelle Backups auf einen anderen Server(rsync), aber das mache ich sicher nicht auf Dateisystem Ebene. Für gute Skalierbarkeit und gute Performance wird XFS empfohlen (wobei JFS wie gesagt noch besser ist, aber die Tools...)

Mich würden mal ein paar praktische Erfahrungen interessieren: Setzt hier jemand XFS oder JFS auf einem produktiven Server ein? Oder würdet Ihr von einem Dateisystem unbedingt abraten?

Oder ist der Unterschied am Ende eh so gering dass man auch gleich beim uralten und bewährten ext3 bleiben sollte? Vielleicht JFS oder XFS nur für die Datenbank-Daten Partition?

Was wäre Eure Empfehlung?


Viele Grüße,
Andreas

[dodolin]

Bisher hab ich auf meinem Root nur ext3 Partitionen, auf meinem nächsten Server, den ich gerade einrichte, werde ich wohl / auf jeden Fall mit ext3 machen, den Rest oder zumindest einiges anderes aber mal testweise mit XFS laufen lassen, welches mir derzeit auch am ehesten einsatzfähig erscheint.

[andreask2]

Mensch, warum schreibst Du nicht sowas wie "ich setze XFS schon seit Jahren auf 20 produktiven Servern ohne jedes Problem ein..." ;-)

Vielen Dank für Deine Einschätzung, auf der einen Seite hätte ich schon gerne die zusätzliche Performance, auf der anderen Seite wäre mir der Preis eines Datenverlustes, einer Inkonsistenz oder eines Absturzes den es mit ext3 nicht gegeben hätte viel zu hoch.
Nur leider kann ich das Risiko überhaupt nicht einschätzen, und "testen" ist auch so ne Sache, im Prinzip bräuchte man einen sehr langfristig angelegten Belastungstest.

Wobei ich hier auch denke, dass die meisten Leute gerade hierbei extrem übervorsichtig sind, und ich denke schon dass es durchaus klappen sollte. Vermutlich ist das Risiko inzwischen nur noch ein theoretisches was sich in den Köpfen festgesetzt hat - wo ReiserFS vermutlich nicht ganz unschuldg dran ist. ;-)

Viele Grüße,
Andreas

[captaincrunch]

Auch ich für meinen Teil setze auf sämtlichen Linux-Kisten ext3 ein, und bin damit hochzufrieden.

Ich kenne allerdings auch ein paar Leute, die sowohl XFS als auch JFS seit längerem ohne Probleme einsetzen. Wie bereits im Artikel genannt sollte gerade JFS, das dem Filesystem unter AIX extrem nahe kommt aber nicht minder "ausgereift" sein.

Letztendlich würde ich mir aber mittlerweile bei keinem der drei genannten FS mehr Sorgen machen, da der gute Linus die nicht in den Vanilla-Kernel aufgenommen hätte, wenn sie nicht mittlerweile recht gut getestet wären.

Sofern du jetzt die berechtigte Frage stellst, warum ich dann immer noch auf ext3 setze, kann ich dir ein paar meiner rein persönlichen Gründe nennen:

1. Never change a running system.
ext3 habe ich jetzt seit mehreren Jahren ohne auch nur das kleinste Problem laufen, und kann mir daher ziemlich sicher sein, dass das auch erstmal so bleibt.

2. Faulheit.
Aufgrund von 1. weiß ich mittlerweile relativ genau, welches "Schräubchen" ich wo drehen muss, um etwas mehr Performance oder Sicherheit herauszuholen. In die anderen FS müsste ich mich erst wieder reindenken/reinarbeiten, wozu ich momentan einfach nicht die Muße habe.

3. Performance.
In den Benchmarks, die ich mittlerweile gelesen habe (wobei erschwerend hinzukommt, dass ich keinem Benchmark traue, den ich nicht selbst gefälscht habe ;) ), hat ext3 in den Anwendungsbereichen, die für mich wichtig sind nicht wirklich übel abgeschnitten. Da darüber hinaus keine meiner Kisten so sehr am Limit wäre, dass ich auch noch das letzte Quentchen Performance aus ihr "rausquetschen" müsste, stören mich die (evtl. auftretenden) "Verzögerungen" im Mili- und Mikrosekundenbereich herzlich wenig.

4. Keep it simple
Durch die o.g. Gründe würde ich mich z.B. auch schwer tun, unterschiedliche FS für unterschiedliche Partitionen einzusetzen, es sei denn, ein Anwendungsbereich würde erheblich davon profitieren (z.B. stark genutzter News-Server). Der Code eines weiteren FS im Kernel bläht mir den dafür einfach viel zu sehr auf, und jede "unnütze" Zeile Code birgt wieder mehr Gefahr von Fehlern.

Fazit für mich ist daher: sofern man es nicht unbedingt braucht, lohnen sich die neuen "modernen" FS nicht allzu sehr, für den "Alltagsgebrauch" reicht ext3 vollkommen aus...oder möchte mir jemand weismachen, dass die billigen Rooties zum "High Performance Computing" taugen würden? ;)

Hth

[andreask2]

Hallo!

3. Performance.
In den Benchmarks, die ich mittlerweile gelesen habe (wobei erschwerend hinzukommt, dass ich keinem Benchmark traue, den ich nicht selbst gefälscht habe ;) ), hat ext3 in den Anwendungsbereichen, die für mich wichtig sind nicht wirklich übel abgeschnitten. Da darüber hinaus keine meiner Kisten so sehr am Limit wäre, dass ich auch noch das letzte Quentchen Performance aus ihr "rausquetschen" müsste, stören mich die (evtl. auftretenden) "Verzögerungen" im Mili- und Mikrosekundenbereich herzlich wenig.

In wieweit unterscheidet sich Dein Anwendungsbereich von dem oben durch mich grob skizzierten Bereich?

4. Keep it simple
Durch die o.g. Gründe würde ich mich z.B. auch schwer tun, unterschiedliche FS für unterschiedliche Partitionen einzusetzen, es sei denn, ein Anwendungsbereich würde erheblich davon profitieren (z.B. stark genutzter News-Server). Der Code eines weiteren FS im Kernel bläht mir den dafür einfach viel zu sehr auf, und jede "unnütze" Zeile Code birgt wieder mehr Gefahr von Fehlern.

Auch ein gutes Argument. Vielen Dank.

Grüße
Andreas

[captaincrunch]

In wieweit unterscheidet sich Dein Anwendungsbereich von dem oben durch mich grob skizzierten Bereich?

Ich habe weder großartige Datenbanken, noch tausende kleine Files in zig Verzeichnissen rumfliegen. ;)

[dea]

Meine 0.2â?¬:

Ich setzte zwar seit Jahren XFS ein (und bin damit auch mehr als zufrieden), würde aber davon abraten, _ein_ Dateisystem als Allheilmittel aller Beschwerden zu betrachten.

Aus eigener, teils leidvoller Erfahrung (und auch, weil ich mir sicher bin, dass die wenigsten das folgende nachahmen werden *fg*):

• / Nie, never ever, unter keinen Umständen ext3 und eigentlich auch nicht JFS, XFS oder ReiserFS (schonmal garnicht). ext2 genügt.
• /usr kann, braucht aber nicht journalling zu sein. Aufgrund der relativen Statik dieses FS ist ein journalling Dateisystem eher optional.
• /usr/src hingegen kann gerne auch journalling sein, da tut sich ja auch öfter was.
• /home sollte, v.a. bei Systemen mit aktiven Usern, sicherlich journalling sein.
• für /opt gilt ähnliches wie für /usr
• /lib darf auch gerne journalling sein, weil ja auch ab und an in Bewegung
• /sbin sollte tunlichst auf ext2 gehalten werden
• /var ist kompliziert, deshalb spalte ich das mal auf Basis von Debian (!) weiter auf:
• /var/lib darf gerne journalling sein, da es für die dort vorgehaltenen Daten(banken) eher auf Konsistenz als auf Aktualität ankommt.
• /var/log sollte tunlichst ext2 sein, da bei Crashes die Logs sehr gerne "zu früh", d.h. einige Zeit vor dem Crash aufhören, da sie wg. des Crashs nicht zurückgeschrieben wurden.

Ich hoffe, ich habe nichts wesentliches ausgelassen.

Hintergrund ist, dass File-Recoveries auf journalling Dateisystemen im Allgemeinen wesentlich schwieriger zu realisieren sind und außerdem das Journal bei bzw. nach einem Crash nicht immer vollständig nachgezogen werden kann und so ggf. Daten verloren gehen.

Die jeweiligen Eigenheiten der unterschiedlichen Dateisysteme optimal auszunutzen ist interessant und hilft ungemein :)

[phil]

Hallo,

hab nen IMAP Server laufen (einzelne Ordner mit über 2500 Mails), vor Monaten auf ext3 mittlerweile auf XFS und habe den Eindruck, daß die Reaktionsgeschwindigkeit merklich zugenommen hat. Hab jedoch nie eine vorher/nachher Messung gemacht. Der Eindruck ist also rein subjektiv. Da ich bisher noch nie einen unerwarteten reboot hatte (toi toi toi) kann ich zu Error Recovery bei XFS nichts sagen.

Grüße

Philipp

[dodolin]

@Phil: Jupp, Directories mit vielen kleinen oder überhaupt mit vielen Dateien sind ein bekannter Schwachpunkt von ext2/ext3, bei dem eigentlich alle anderen hier genannten Dateisysteme besser sind.

[majortermi]

Ich setze seit einiger Zeit XFS ein und bin damit sehr zufrieden. Zur Performance kann ich wenig sagen, da bei mir eigentlich kaum kritische I/O-Vorgänge stattfinden, mit dem Recovery hatte ich dank Journal bislang keinerlei Probleme - das geht im Vergleich zu ext3 wesentlich schneller.

Nett ist außerdem ACL- und Quota-Unterstützung (was letzteres angeht ist XFS neben ext2/ext3 meines Wissens momentan das einzige Filesystem unter Linux mit entsprechender Unterstützung).

In meinen Augen spricht ebenfalls für XFS, dass es sich um ein relativ "altes" Filesystem handelt, damit also schon viel Erfahrung gesammelt wurde, da es auf unter IRIX bereits seit Jahren benutzt wird.

[Anonymous]

Hi,

ich hatte ein JFS-Filesystem über ein Loopback-Device mit 32GB in Benutzung, um Datensicherungen mit RSync durchzuführen.

Entweder stürzte die Maschine alle 5-7 Tage ab oder Zugriffe auf das JFS-Filesystem blieben hängen (Kernel 2.4.25):

kernel: BUG at jfs_dtree.c:3326 assert((btstack)->top != &((btstack)->stack[MAXTREEHEIGHT]))
kernel: kernel BUG at jfs_dtree.c:3326!
kernel: invalid operand: 0000
kernel: CPU: 0
kernel: EIP: 0010:[dtReadFirst+389/544] Not tainted
kernel: EIP: 0010:[<c01b38a5>] Not tainted
kernel: EFLAGS: 00010286
kernel: eax: 00000058 ebx: c1546000 ecx: c3caa000 edx: cdd1ff7c
kernel: esi: cbacd974 edi: 005135af ebp: 00000000 esp: c3cabe00
kernel: ds: 0018 es: 0018 ss: 0018
kernel: Process ls (pid: 4156, stackpage=c3cab000)
kernel: Stack: c02adc81 c02adfa5 00000cfe c02b8960 00000000 cf772a60 c59cba20 00000000
kernel: c3cabfa4 cac15720 c01b34e7 c59cba20 c3cabeb4 00000002 00000001 00000000
kernel: 00000002 00000004 c1094428 00000001 000025e9 000025e9 00000286 00000000
kernel: Call Trace: [jfs_readdir+2439/3008] [add_timer+16/64] [vfs_readdir+166/176] [filldir64+0/272] [sys_getdents64+91/192]
kernel: Call Trace: [<c01b34e7>] [<c0120000>] [<c0147cd6>] [<c0148380>] [<c01484eb>]
kernel: [filldir64+0/272] [sys_brk+264/320] [system_call+51/56]
kernel: [<c0148380>] [<c0127878>] [<c010735f>]
kernel: Code: 0f 0b fe 0c a5 df 2a c0 e9 58 ff ff ff 8

Zu XFS kann ich nichts sagen.

Nachdem ich das JFS-Filesystem durch ein Reiser-Filesystem ersetzt habe, gibt es keine Crashs mehr...

Das Filesystem hat 4.500.000+ Dateien mit über 99% Hardlinks...

:-)