ReiserFS oder XFS (oder gar JFS)?

[theomega]

Hallo Leute,
ich stehe beim neuen Aufsetzten eines Servers (Gentoo, Kernel 2.6.17) vor der Frage welches Dateisystem ich für die Datenspeicher benutze. Dabei geht es um vier Partitionen:
1. Die Hauptpartition mit den Programmen, wird kaum geändert, deshalb eigentlich nicht so wichtig
2. Die Parition /var wo vor allem die Logs liegen (kein Mailserver, Datenbanken auf andere Parition)
3. Die Parition /var/lib/mysql wo die MySQL-Datenbanken liegen
4. Die Parition /home wo die HTML-Inhalte liegen. Dabei handelt es sich aber ausschließlich um Bilder, die dynamischen Inhalte werden nicht auf diesem Server erstellt. Als HTTP-Server soll lighttpd zum Einsatz kommen.

Auf meinem Desktop daheim habe ich reiserfs im Einsatz und bin sehr zufrieden, vor allem darüber das das System auch nach einen Crash wieder benutzbar ist (daran scheiterte ext3 bei mir regelmäßig). Jetzt habe ich aber bei einigem Tests im INet gesehen das Reiserfs von der Geschwindigkeit her nicht so optimal ist, und XFS besser wäre.
Wie sieht es damit aus? Ist der XFS-Support im Kernel stable? Was würdet ihr nutzen?

Danke schonmal
TO

[cosmo]

http://www.debian-administration.org/articles/388

XFS läuft bei mir auf allen Servern stabil.

Gruß

[theomega]

Den Artikel kannte ich bereits, danke schön. Der Test sah mir aber nicht so ganz aussagekräftig aus und außerdem mehr Desktop-Orientiert!

[daemotron]

Tja, ich hab in meinem Test-Setup folgende Konfiguration:

Code: Select all

/                               => ext3
/boot                           => ext2
/var           logs, mails      => xfs
/export/data   MySQL data files => reiserfs 3.6
/export/log    MySQL bin-logs   => reiserfs 3.6

[EDIT] P.S. von JFS würde ich mal absehen... angeblich soll es ganz stabil laufen, aber so richtig traue ich der Sache noch nicht (das Gentoo-Handbuch übrigens auch nicht...)

[theomega]

Wobei, wenn du LFS im Einsatz hast XFS doch den entscheidenden Nachteil hat, das du die Paritionen nicht verkleinern kannst, oder? Das ist halt der Vorteil von Reiser! Sonst danke für den Link, werde ich gleich durchlesen.

[oxygen]

Ich bin da nicht so exotisch orientiert.
/var und /home reiserfs, Rest ext3.

[daemotron]

OK, die Konfiguration mit mehr als zwei Dateisystemen ist etwas extrem - hatte das wie gesagt auch nur auf meiner Testmaschine so aufgesetzt. Meine Beweggründe: XFS ist sehr performant - auch bei kleineren Dateien und eignet sich daher ziemlich gut für Webseiten-Bestandteile (im Ggs. zu ext3, das trotz Tuning diese Performance einfach nicht erreichen kann). ReiserFS 3.6 wird von MySQL ausdrücklich empfohlen (finde grade den Link nicht, aber ich meine, Isotopp hat mal was in die Richtung verlauten lassen). JFS ist mir noch zu experimentell, und auf andere Exoten wollte ich mich auch nicht unbedingt einlassen... Auf einem Produktivsystem würde ich mich entweder für XFS oder für ReiserFS entscheiden.

[daemotron]

Wobei, wenn du LFS im Einsatz hast XFS doch den entscheidenden Nachteil hat, das du die Paritionen nicht verkleinern kannst, oder?

Jupp, weder XFS- noch JFS-Partitionen lassen sich verkleinern (siehe LVM Howto von AJ Lewis). Allerdings sehe ich nicht unbedingt die Notwendigkeit, Partitionen zu verkleinern. Ich weise zu Beginn jeder Partition nur ein Minimum an Speicherplatz zu, und bei Bedarf schiebe ich immer ein Häppchen Plattenplatz nach (daher auch die 16 logischen Partitionen...), der Rest bleibt ungenutzt und wird keiner Volume Group zugewiesen. Gewissermaßen simuliere ich auf diese Weise das Plattenmanagement "echter" Unix-Systeme (Solaris lässt grüßen) Und vergrößern kann man sowohl XFS als auch JFS, und zwar in gemountetem Zustand (siehe LVM HOWTO). So komme ich dann immer noch in den Genuss der besseren Performance von XFS gegenüber Reiser und ext3...

[captaincrunch]

Und vergrößern kann man sowohl XFS als auch JFS, und zwar in gemountetem Zustand (siehe LVM HOWTO).

Nur, weil noch nicht alle Distributionen die nötigen Patches intus haben, heißt das noch lange nicht, dass eine Vergrößerung von ext3 im laufenden Betrieb nicht auch machbar wäre. ;)

CC, der mittlerweile auf seinen Notbüchern sowohl JFS als auch XFS im Einsatz hat (mit XFS aber subjektiv zufriedener ist).

[daemotron]

Unless you have patched your kernel with the ext2online patch it is necessary to unmount the file system before resizing it. (It seems that the online resizing patch is rather dangerous, so use at your own risk)

ext3 wäre mein FS der Wahl (von der Stabilität und vom Resize-Verhalten her), wenn denn die Performance stimmen würde... Reicht leider bei weitem nicht an XFS heran. Hmm, vielleicht doch lieber UFS2 einsetzen? 8)

[captaincrunch]

Hast du mal geschaut, wann der Kommentar bzgl. des Patchs ins Howto eingeflossen ist? Ich hab's schon ein paar Mal durchgezogen, und bislang lief alles glatt (knock on wood).

Wie wär's denn gleich mit ZFS? ;)

[Roger Wilco]

Wie wär's denn gleich mit ZFS? ;)

Vielleicht gar nicht so abwegig: http://www.wizy.org/wiki/ZFS_on_FUSE ;)

[theomega]

Hm, interessant, aber was kostet den das checksum-bilden und die anderen features an prozessor-leistung? ich wills garnicht wissen.

[daemotron]

8) Sun hat ZFS ja auch nicht für 2.4 GHz-Celerons mit IDE-Platten und 512 MB RAM konzipiert... eher für sowas *MUAHAHAHA*

@CC: muss spätestens 2004 gewesen sein, da wurde der entsprechende Abschnitt das letzte Mal überarbeitet... :oops:

[isotopp]

Hm, interessant, aber was kostet den das checksum-bilden und die anderen features an prozessor-leistung? ich wills garnicht wissen.

Das ist alles ziemlich irrelevant, in erster Näherung jedenfalls.

RAM = Access times im Bereich 10E-9 für einzelne Bytes, also 10E-6 für KB.

Platte = Access times im Bereich 10E-3 für Blöcke von 512B.

Also ist RAM zwischen 1E6 und 1E3 schneller als Platte. Du hast also zwischen 1000 und 1000000 Prozesorzyklen Zeit, bevor Ram langsamer wird als Platte - pro Block.

[Anonymous]

Ich habe unter OpenSUSE 10 verschiedene Performance- und Crash-Tests durchgeführt, um den ideale Filesystem-Typ zu ermitteln. Und wie's immer ist, es gibt keine eindeutige Antwort. Jedes Filesystem hat seine Vor- und Nachteile.

ReiserFS
+ sehr einfach zu vergrössern und zu verkleinern
+ besste Speicherplatz-Nutzung (kaum Overhead)
+ besste Performance beim Zugriff auf kleine Dateien
- braucht am längsten für mount/dismount
- scheint mir nicht so crash-sicher
- sehr hohe CPU-Last bei Dateisuche/-listing

JFS
+ besste Performance beim Zugriff auf grosse Dateien
+ geringste CPU-Last
+ schnellster mount/dismount
+ sehr stabil im Crash-Fall
- langsam bei Dateisuche/-listing
- kann nicht verkleinert werden
- /boot will manchmal nicht booten (sehr eigenartig)

XFS
+ besste Performance bei langen und vollen Trees
+ geleichmässige Performance beim Zugriff auf Dateien unterschiedlicher Grösse
- kann nicht verkeinert werden
- relativ hohe CPU-Last bei Dateisuche/-listing

ext3
+ besste Performance beim Vergleich von Dateiinhalten
+ besste Performance beim Kopieren von ganzen Verzeichnisbäumen
+ relativ geringe CPU-Last
- macht nicht den stabilsten Eindruck bei Crashes
- ungewöhnlich schlechte Performance beim Löschen von Dateien
- langsam bei Dateisuche/-listing

Fazit:
Als Fileserver eignet sich XFS wohl am besten, da durchgehend gute Werte erzielt werden. Als Datenbank-Server mit grossen DB-Files und intensiver Nutzung ist JFS unschlagbar. Ein Webserver mit vielen kleinen und kleinsten Dateien ist mit ReiserFS gut bedient.

Schockierend war für mich, wie die CPU-Leistung dramatisch zusammenbrach, wenn man mit ReiserFS auf wirklich grosse Dateien (> 1 GB) los ging.

Interessant finde ich, dass ext3 am schnellsten Files anlegt, aber dafür mit Abstand am längsten braucht, um sie wieder zu löschen. Im Allgemeinen dünkt mich ext3 beim möglichen Einsatzzweck mit XFS konkurierend. XFS wirkt aber stabiler und ausgeglichener.

[lord_pinhead]

Mit welcher Version von ReiseFS hast du getestet? Bin kein Freund von Reiser weil der Support damals einfach vom Erfinder eingestellt wurde bzw. stark vernachlässigt und er sich dem nachfolger, Reiser4, gewidmet hat.

Ext3 hat noch den Nachteil das kein Undelete mehr geht wie bei Ext2, was es bei einem Einbruch in den Server schwer macht mit der Forensik. Reiser, XFS und JFS sollten soetwas haben, jedenfalls sollte das Journal erhalten bleiben.

Für das OS selbst verwende ich allerdings immernoch Ext3 und nur für /home oder /var nehme ich XFS. Auf dem Rootservern ist allerdings ext2 durchgängig im Einsatz seit mal jemand eingestiegen ist und kein Forensiktool mehr die Logfiles wiederherstellen konnte (ext3 sei dank).

Also wie du schon sagtest, jedes Dateisystem hat seine Vor- und Nachteile. Je nach gegebenheit sollte man ein Dateisystem wählen das dafür gut geeignet ist. Allerdings ist für mich XFS für alles geeignet was mit viel Dateien zu tun hat da ein Dateisystemcheck extrem schnell abläuft und ich es bisher nocht nicht geschafft habe das System inkonsistent zu bekommen, nur 1 Netzteil hat den Geist aufgegeben durch das an und abschalten im Betrieb ;)

[isotopp]

Mit welcher Version von ReiseFS hast du getestet?

Reiserfs 3.6 ist das Standard-Dateisystem bei Suse Linux. Suse bezahlt auch Entwicklung und Pflege dafür bei Reiser. Suse würde das nicht einsetzen, wenn es viel Ärger beim Support machte...

[daemotron]

[zu ReiserFS] - scheint mir nicht so crash-sicher

Woran machst Du das fest? Eher ein Gefühl, oder hast Du's geschafft, einen (irreparabel) inkonsistenten Zustand herbeizuführen?

Hatte nämlich geplant, damit meine LVs für MySQL zu bestücken. Wenn reiser nicht crash-stabil ist, wäre das gar keine gute Idee... :?

[r. u. serious]

Ich habe unter OpenSUSE 10 verschiedene Performance- und Crash-Tests durchgeführt, um den ideale Filesystem-Typ zu ermitteln.

Hast du die Rohdaten der Ergebnisse noch irgendwo liegen? Das wär ganz interessant, auch welche konkreten Versionen du bspw. genutzt hat.
Z.B. die Crash-Sicherheit bei Reiser war AFAIK nur ein temporäres Problem bei wenigen konkreten Versionen die mitterweile seit längerem der Vergangenheit angehören sollen (nur gelesen, keine persönliche Erfahrung).

[adjustman]

Und vergrößern kann man sowohl XFS als auch JFS, und zwar in gemountetem Zustand (siehe LVM HOWTO)

Da hab ich mal ne Frage. Hab da

Code: Select all

/dev/md6              4,7G  4,7G   33M 100% /var
/dev/md7              100G   26G   74G  26% /home

beide xfs. Nun wollt ich die /var vergrößern auf 20GB
und /home auf 80 GB verkleinern. In der fstab steht

Code: Select all

/dev/md6	/var	xfs	defaults,usrquota	0	2
/dev/md7	/home	xfs	defaults,usrquota	0 2

Kann da jemand mal ne Hilfestellung geben, wie ich die neue Größe
definiere? Danke.

[juergen]

Mit welcher Version von ReiseFS hast du getestet?

Reiserfs 3.6 ist das Standard-Dateisystem bei Suse Linux. Suse bezahlt auch Entwicklung und Pflege dafür bei Reiser. Suse würde das nicht einsetzen, wenn es viel Ärger beim Support machte...

Bezahlt SuSE auch den Anwalt von Reiser?

[Roger Wilco]

beide xfs. Nun wollt ich die /var vergrößern auf 20GB
und /home auf 80 GB verkleinern.

Online verkleinern und vergrößern von Partitionen ist nicht unbedingt einfach. Das Dateisystem muss das z. B. unterstützen. XFS-Dateisysteme kann man nur vergrößern (-> `man xfs_growfs`), verkleinern ist nicht möglich. Dazu muss das Dateisystem neu erstellt werden und es gehen alle Daten darauf flöten.

So wie ich das sehe benutzt du ein Software-RAID, d. h. du müsstest erstmal die unterliegenden Partitionen vergrößern bzw. verkleinern. Dazu löschst du /dev/md7 (bzw. die unterliegenden Partitionen) und vergrößerst /dev/md6 auf die gewünschte Größe. Mit xfs_growfs wird das Dateisystem an die neue Partitionsgröße angepasst. Danach kannst du /dev/md7 neu erstellen und mit mkfs.xfs formatieren.
Die Daten in /home musst du also vorher komplett sichern.

Bezahlt SuSE auch den Anwalt von Reiser?

Da ReiserFS nicht mehr das Standard-Dateisystem für SLES/SLED bzw. OpenSuSE ist, wird das wohl nicht nötig sein. ;)
Außerdem erfährt ReiserFS AFAIK nur noch kritische Bugfixes. Eine Weiterentwicklung findet nicht mehr statt. Wohlgemerkt bei ReiserFS, Reiser4 ist eine andere Geschichte.

[adjustman]

Online verkleinern und vergrößern von Partitionen ist nicht unbedingt einfach

ja, das glaub ich. :(
Mir geht es darum, dass das /var (durch exessiven Upload der User)
vollläuft und in /home noch viel Platz wäre.
Da wollt ich was ändern. Gibts da auch nen anderen Weg?

[Roger Wilco]

Gibts da auch nen anderen Weg?

Du könntest die Verzeichnisse in /var, welche viel Festplattenspeicher benötigen, auf /home auslagern. Entweder indem du den Speicherort in der jeweiligen Konfigurationsdatei änderst (z. B. /etc/my.cnf für die MySQL-Datenbank) oder indem du die Verzeichnisse mit der mount-Option "--bind" einbindest und dann unter /home speicherst.