Linux filesystem Vergleich

PuckPoltergeist

Grand Admiral Special
Mitglied seit
18.01.2002
Beiträge
16.734
Renomée
145
Standort
Ilmenau
Da es unter Linux ja nun wahrlich nicht wenige Dateisysteme gibt, und dadurch auch immer wieder die Frage aufkommt, welches man denn nun verwenden soll, habe ich mich entschlossen, die Alternativen mal ein einem separaten Thread gegenüber zu stellen. Dabei sollen die jeweiligen Eigenschaften der Dateisysteme dargestellt werden und objektive wie subjektive Einschätzungen/Meinungen repräsentiert werden. Resultieren soll das ganze dann mal in Tips und Vorschlägen wie:
* für Einsatzzweck X ist besonders Dateisystem M zu empfehlen
* bei Einsatzzweck Y ist Dateisystem N erste Wahl
* für Szenario Z ist Dateisystem O denkbar ungünstig geeignet

Diese Tips sollen sich natürlich in erster Linie an objektiven Kriterien orientieren, wobei ein gewisses Maß an Subjektivität nicht auszuschließen und vielleicht auch ganz gesund ist.
Bei entsprechender Qualität des Threads könnte der dann vielleicht auch gepinnt werden, wobei dann eine Zusammenfassung der Ergebnisse im ersten Posting gepflegt wird. Ich hoffe dabei auf gute Mitarbeit und Feedback von euch. ;)
 
Also ich würde für den Einsatz als Root-Dateisystem auf jedenfall das ext3-Dateisystem empfehlen. Einerseits liegt es auf der Hand, dass dieses Dateisystem, welches nicht umsonst von einigen der größten Distributionen, wie Debian und Novell SuSE, genutzt wird, nicht nur sehr flexible sondern auch verhältnissmäßig (in betracht auf die funktion) schnell und sicher ist. So ist es bspw. möglich bei ext3 die Dateisystemgröße nachträglich im laufendem Betrieb zu ändern. Dies kann bspw. ext2 nicht. Weiterhin finde ich sehr positiv, dass die Dateigültigkeit, sollte einmal im Fall X das überschreiben von Daten schiefgehen (der Rechner stürzt ab oder so), bestehen bleiben. Zugegeben... das machen alle Journaling-Dateisysteme, aber ich finds halt sehr positiv! Ein "Manko", dass ich leider auch schonmal am eigenem Leib erfahren habe gibt es jedoch! Wenn man bei ext3 Daten dauerhaft loescht! Dann sind sie auch weg! Ich habe bisher noch keine Möglichkeit gefunden mit OnTrack und Co. Daten wiederherzustellen. Leider...

Ich persönlich habe jedoch prinzipiell nur gute Erfahrungen mit ext3 Partitionen gemacht und werde diese auch weiterhin nutzen.
 
Dann will ich auch gleich mal mit dem ersten Vergleich anfangen. Habe die letzten paar Tage hier mal die üblichen Verdächtigen (ext2/3, jfs, reiser4, reiserfs, xfs) gegeneinander antreten lassen. Der erste Test war noch sehr simpel, und bestand lediglich aus dem messen der Zeit, die zum kopieren von Dateien auf der selben Partition benötigt wurde. Ich habe das in zwei Szenarien aufgeteilt, einmal mit wenigen großen Dateien und dann mit vielen kleinen Dateien. Der Testrechner war ein Schlepptopf mit folgenden Daten:
Prozessor: PIII 1GHz
RAM: 512MB
HDD: IBM Travelstar, 48GB, 5400rpm
OS: Gentoo-Linux unstable (linux-2.6.18, gcc-4.1.1, glibc-2.4)

Der Kernel ist mit Reiser4 gepatcht, um das FS auch gleich zu testen. Dazu habe ich den 2.6.17-patch von namesys auf den 2.6.18er Kernel portiert. Ansonst ist der Kernel vanilla.

Für den Test hat eine ~11GB große Partition auf der Platte hergehalten, auf welche ich die einzelnen Dateisysteme losgelassen habe.

Die zwei Testszenarien sahen folgendermaßen aus:
bigfile
kopieren eines Verzeichnes mit 4 1GB großen Dateien aus /dev/urandom in ein anderes Verzeichnis mittels
time cp -a dir1/ dir2

smallfile
kopieren eines Verzeichnis mit insgesamt ~1.8GB kleiner Dateien in ein anderes Verzeichnis; als "Testopfer" dienten mir die svn-trees von KDE und KOffice mit
time cp -a KDE/ KDE2

Ablauf war immer der folgende:
Partition mit FS formatieren
Partition mounten
Schreibrechte für normalen Nutzer geben
Testdaten auf Testpartition kopieren
Testlauf durchführen
Partition unmounten

Die Ergebnisse (1 Lauf jeweils) sehen folgendermaßen aus:
ext2:
bigfiles 4x1GB
real 13m9.403s
user 0m0.408s
sys 0m40.019s
smallfiles
real 13m29.991s
user 0m4.116s
sys 0m47.899s

ext3:
bigfiles 4x1GB
real 13m43.595s
user 0m0.440s
sys 0m50.171s
smallfiles
real 18m42.383s
user 0m4.696s
sys 0m59.300s

jfs:
bigfiles 4x1GB
real 13m20.214s
user 0m0.448s
sys 0m40.935s
smallfiles
real 22m53.825s
user 0m3.556s
sys 0m44.351s

reiser4:
bigfiles 4x1GB
real 11m58.412s
user 0m0.384s
sys 1m1.932s
smallfiles
real 6m2.483s
user 0m5.720s
sys 1m48.023s
umount
real 0m37.611s
user 0m0.000s
sys 0m1.052s

reiserfs:
bigfiles 4x1GB
real 13m10.917s
user 0m0.388s
sys 1m9.056s
smallfiles
real 13m45.977s
user 0m7.804s
sys 1m51.475s
umount
real 0m2.173s
user 0m0.000s
sys 0m0.468s

xfs:
bigfiles 4x1GB
real 13m4.014s
user 0m0.448s
sys 0m43.867s
smallfiles
real 32m4.985s
user 0m7.972s
sys 1m55.219s
umount
real 0m1.263s
user 0m0.000s
sys 0m0.708s

Die Werte sprechen erstmal für sich, sind aber zumindest für mich doch schon etwas überraschend. Ab Reiser4 habe ich dann auch die Zeiten für das unmounten gemessen, weil das Ergebnis dort etwas kurios war. Die Kopieroperation war extrem schnell, das unmounten hatte aber extrem lange gedauert. Deshalb ist Reiser4 auch das einzige FS, welches ich zweimal getestet habe, um die Zeiten für das umount auch zu bekommen. Die Werte sind komplett aus dem zweiten Test, wobei ich der Meinung bin, dass das umount beim erstmal noch deutlich länger gedauert hatte. Für ReiserFS und XFS habe ich die Zeiten für das umount dann zu Vergleichszwecken mitgenommen.
Die gemessenen Zeiten sagen jetzt nicht nur etwas über die Performance aus, sondern auch w ie stark das jeweilige FS die CPU belastet (sys).

Das ist jetzt nur der erste kleine Test. Ich gedenke das noch deutlich auszuweiten, und auch andere Kriterien dabei einzubeziehen.
Falls jemand selber gerne mit Reiser4 rumspielen möchte, stelle ich den Patch für 2.6.18 gerne zur Verfügung. Für 2.6.17 gibt es ihn ja direkt von namesys. Dazu gilt aber folgende Wahrnung:
Reiser4 sollte niemals nicht auf keinen Fall auf einem Produktivsystem oder gar einer Partition mit Produktivdaten eingesetzt werden! Es ist nicht stabil!
 
Ich bin zur Zeit auf Auslandssemester in Schweden und kann daher nicht selbst nachgucken, aber im Linux Magazin 10/2005 war ein Artikel "Benchmark: Was Reiser-FS, Ext 3, XFS und Reiser 4 leisten". Vielleicht hat den jemand anders verfügbar (Online lesen kann man ihn leider nicht) und kann zumindest die Ergebnisse hier posten?
 
Ich bin zur Zeit auf Auslandssemester in Schweden und kann daher nicht selbst nachgucken, aber im Linux Magazin 10/2005 war ein Artikel "Benchmark: Was Reiser-FS, Ext 3, XFS und Reiser 4 leisten". Vielleicht hat den jemand anders verfügbar (Online lesen kann man ihn leider nicht) und kann zumindest die Ergebnisse hier posten?
Mache ich morgen. Ich glaube mich aber zu erinnern, dass die Ergebnisse dort sich signifikant von meinen unterscheiden. Ich will meine Ergebnisse jetzt allerdings auch nicht überbewerten, da es jeweils nur ein Lauf war. Eine deutliche Tendenz wage ich aber schon abzulesen, auch wenn sie mir persönlich nicht gefällt. ;D
 
Bin auch an einem Vergleichstest interessiert.

Allerdings interessiert mich jetzt eher weniger die Performance, aber da mein S271
nächste Woche Gentoo übergeprügelt bekommt hab ich mir (allerdings auch schon
vor einer Weile) Gedanken zu dem Dateisystem gemacht.
Bisher, bei Desktop PCs hab ich im Zweifelsfall immer Reiser genommen, weil ich
damit noch nie Probleme hatte (hätte auch ext3 nehmen können).

Jetzt hab ich allerdings irgendwo mal gelesen, dass unterschiedliche Dateisystem
den Akku unterschiedliche stark belasten, d.h. also, dass die Festplatte evtl.
öfter anspringen muss etc.
Leider war das bei dieser Quelle nicht genauer spezifiziert, mich würde aber
wirklich interessieren, ob es beim Stromverbrauch Unterschiede gibt.
Ich hab mal gelesen, das XFS da sehr gut sei, allerdings ist es für Notebooks
ja nun nicht so geeignet. Überhaupt fehlen mir ein bisschen die Szenarien, in denen
ich JFS oder XFS den etablierten vorziehen würde.
 
Jetzt hab ich allerdings irgendwo mal gelesen, dass unterschiedliche Dateisystem
den Akku unterschiedliche stark belasten, d.h. also, dass die Festplatte evtl.
öfter anspringen muss etc.

Das hängt direkt mit der CPU-Belastung durch das jeweilige FS zusammen. Je CPU-lastiger, desto höher logischerweise der Stromverbrauch. Darauf und auf dein zweites Problem, die Robustheit und Datensicherheit werde ich auch noch explizit eingehen. Gib mir nur ein wenig Zeit. Sowas möchte auch fundiert begründet werden, sprich mit Messwerten. ;)

Reiser4?
Wenn ja, was gefällt dir daran nicht? (Meinerseits wertfrei, weil ich es nicht kenne)

Nun, einerseits wegen direkter und indirekter Erfahrungen mit ReiserFS. Zusätzlich kenne ich mittlerweile auch den Code von Reiser4 ein wenig, und ich glaube zu ahnen, wo es den Geschwindigkeitsvorteil herzieht. Und das gefällt mir absolut nicht, weil es böse Nebenwirkungen hat.
 
Ich hab mal gelesen, das XFS da sehr gut sei, allerdings ist es für Notebooks
ja nun nicht so geeignet.

Im gentoo Handbuch stand mal, dass man XFS für Notebooks nicht einsetzen sollte, da es Probleme geben könnte, sollte das Notebook plötzlich vom Strom getrennt werden (sei es durch Akku leer oder was auch immer), allerdings glaube ich nicht, dass bei umsichtiger Handhabung seitens des Users das Probleme bereiten könnte, zumindest nicht mehr, als auf nem Desktop.
Inzwischen steht dort allgemeiner: "XFS ist ein Dateisytem mit Metadata-Journaling, das mit einer Menge robuster Fähigkeiten glänzt und auf Skalierbarkeit ausgelegt ist. Wir empfehlen den Einsatz dieses Dateisystems nur auf Linux-Systemen mit High-End-SCSI und/oder Fibre-Channel-Storage und einer redundaten Stromversorgung. Da XFS agressiv vom RAM gebraucht macht, können unsachgemäß designte Programme (solche die keine Vorsichtsmaßnahmen treffen, wenn Sie auf die Festplatte schreiben und davon gibt es einige) dazu führen, dass eine ganze Menge Daten verloren gehen, wenn das System unerwartet ausfällt."
Ansonsten wüßte ich von keinen Schwierigkeiten von XFS mit Notebooks...
 
Im Prinzip hab ich genau das gemeint.
Jetzt weiß ich auch, wo ich das gelesen hab. ;)

Allerdings hab ich auch schon vorher in einem Forum was über
XFS gelesen, dass kann sich aber auch einfach nur auf das HB
bezogen haben.
 
Auf meinem Notebook setzte ich auch ext3.
Reiserfs greift mir zu oft auf die Harddisk zu, deshalb wacht die Harddisk staendig aus dem sleep auf.

Meiner meinung nach ist ext3 nicht langsamer als ReiserFS nur beim Löschen (mal erhlich wie oft löscht man etwas)
Hinzukommt das ReiserFS mehr die CPU benasprucht als ext2/3.

Ich hatte sehr lange ReiserFS verwendet, nun bin ich wieder zu ext3 zurueck gekehrt bis ZFS oder ext4 im Kernel sind.
((( MEINE MEINUNG)))
 
Auch durch an Anregung von Monstar, es wäre doch mal interessant, die Filesystem
zu testen, wenn nicht kontinuierlich Datein geschrieben würden, sondern z.B.
alle 10 Sekunden ne zufällige Datei und dabei dann die Last der CPU messen.
 
benchmark ergebnisse von "Filesystems (ext3, reiser, xfs, jfs) comparison on Debian Etch" druchgeführt durch Debian Administration.
 
Ich habe XFS unter Ubuntu laufen (Notebook und Desktop) und hatte damit noch keine Probleme...

Es gibt direkt eine Benchmark-Suite für Unix-Dateisysteme: bonnie
 
So etwas ähnliches gab es auch mal hier:

http://linuxgazette.net/102/piszcz.html

Interessant wären für mich auch folgende Punkte:
1. Performance in Abhängigkeit von der CPU
-> das Testsystem ist ja nicht sehr aktuell, möglicherweise sieht es auf modernen Rechnern schon wieder ganz anders aus.
2. Mounten von Partitionen mit mehr als 100GB
3. Fsck von Partitionen größer 100GB

XD
 
Hab mir mal den Test angeguckt, wenn da jeder was anderes rausbekommt, sollte man besser erstmal über die Testbedingungen nachdenken.
 
http://www.debian-administration.org/articles/388

Da ist ReiserFS zB. eher langsamer, bei dir ist es eher schneller als ext3.

Das ist nicht direkt vergleichbar, da dort mit zwei Platten gearbeitet wurde, während ich nur auf einer getestet habe. Außerdem sind die Ergebnisse teilweise extrem Hardware abhängig. Ich wiederhole die Tests gerade nochmal auf meiner großen Kiste (der 144er Opteron). Die Ergebnisse sind noch nicht fertig, aber ich verspreche euch jetzt schon Resultate, die euch vom Hocker hauen dürften. Mir ging es jedenfalls so. ;D
 
So, hier jetzt wie versprochen die Testergebnisse von meinem großen Rechner. System sah folgendermaßen aus:

Opteron 144 (1.8GHz)
1.5GB RAM
36GB SCSI HDD 10k rpm
Tekram U2W SCSI Controller

Für den Test stand die gesamte Platte zur Verfügung. Ich habe für jeden Test das jeweilige Dateisystem jungfräulich mit den default-Parametern aufgesetzt und gemountet. Test bestand wieder aus zwei Szenarien, einmal große und einmal kleine Dateien. Für die großen Dateien habe ich diesmal 4 2GB Dateien aus /dev/urandom erstellt, und das Verzeichnis mit diesen Dateien dann kopiert. Für die kleinen Dateien kam wieder der svn-tree von kde und KOffice zum Einsatz + ein paar Zusätze (qt-copy, kdenonbeta, playground...). Alles in allem summierte sich das auf 3.3GB Daten. Die Erhöhung des Datenvolumens war deshalb notwendig, um den Test nicht komplett im RAM laufen zu lassen.

Die Ergebnisse sehen jetzt folgendermaßen aus:
ext2:
bigfiles
real 8m4.989s
user 0m0.200s
sys 0m21.349s
smallfiles
real 16m6.699s
user 0m3.040s
sys 0m32.006s

ext3:
bigfiles
real 7m11.251s
user 0m0.260s
sys 0m39.706s
smallfiles
real 19m57.863s
user 0m3.272s
sys 0m46.755s

jfs:
bigfiles
real 6m57.806s
user 0m0.192s
sys 0m20.473s
smallfiles
real 58m45.392s
user 0m3.280s
sys 0m41.879s

reiser4:
bigfiles
real 5m39.660s
user 0m0.036s
sys 0m32.294s
smallfiles
real 5m35.992s
user 0m3.156s
sys 1m19.369s

reiserfs:
bigfiles
real 8m15.467s
user 0m0.028s
sys 0m23.505s
smallfiles
real 12m11.488s
user 0m4.108s
sys 1m18.181s

xfs:
bigfiles
real 6m17.051s
user 0m0.204s
sys 0m21.521s
smallfiles
real 38m20.340s
user 0m3.516s
sys 1m4.292s
 
Sehr interessant. Also reiserfs scheint da schon die ein oder andere CPU in die Knie zu zwingen, wobei die Zeiten von reiser4 schon extrem gut sind (btw. wie lange hat er denn da beim unmounten gebraucht?).
Das JFS so grottig abschneidet hätte ich auch nicht gedacht.

Bei mir ist grad 'ne neue Platte reingewandert, vielleicht mach ich da auch noch ein paar Vergleiche.
 
Sehr interessant. Also reiserfs scheint da schon die ein oder andere CPU in die Knie zu zwingen, wobei die Zeiten von reiser4 schon extrem gut sind (btw. wie lange hat er denn da beim unmounten gebraucht?).
Die Zeiten vom unmount sind nicht wirklich vergleichbar, weil ich nicht bei jedem Test sofort nach dem kopieren umount gemessen habe. Da sind teilweise ein paar Minuten Unterschied, die die Zeiten massiv beeinflussen können. Hier mal die Werte:
ext2:
bigfiles
umount
real 0m4.498s
user 0m0.000s
sys 0m0.392s
smallfiles
umount
real 0m1.605s
user 0m0.000s
sys 0m0.784s

ext3:
bigfiles
umount
real 0m0.591s
user 0m0.000s
sys 0m0.364s
smallfiles
umount
real 0m1.205s
user 0m0.000s
sys 0m0.896s

jfs:
bigfiles
umount
real 0m3.689s
user 0m0.000s
sys 0m0.236s
smallfiles
umount
real 0m0.224s
user 0m0.000s
sys 0m0.004s

reiser4:
bigfiles
umount
real 0m3.609s
user 0m0.000s
sys 0m0.984s
smallfiles
umount
real 0m11.540s
user 0m0.000s
sys 0m1.220s

reiserfs:
bigfiles
umount
real 0m0.753s
user 0m0.000s
sys 0m0.432s
smallfiles
umount
real 0m1.266s
user 0m0.004s
sys 0m0.864s

xfs:
bigfiles
umount
real 0m3.754s
user 0m0.000s
sys 0m0.352s
smallfiles
umount
real 0m25.781s
user 0m0.000s
sys 0m1.116s

Liegen also nicht so weit auseinander, und gerade Reiser4 schneidet diesmal recht gut ab. Aber wie gesagt, die Werte sind nur sehr bedingt aussagekräftig.

Das JFS so grottig abschneidet hätte ich auch nicht gedacht.
Ich auch nicht, und ich werde dem auch mal weiter nachgehen. Und auch XFS steht nicht gerade gut da. Das hat die zweitschlechtesten Zeiten bei kleinen Dateien, die auch noch ziemlich mies sind. Dass sie gerade gegen ext3 so schlecht sind, hätte ich nie erwartet.

Wenn man nach der Performance geht, währen die Reiser-Dateisysteme die erste Wahl, Reiser4 und danach ReiserFS. Wenn die Teile nur nicht so notorisch buggy wären. Beim Test sehr interessant, aber meine Daten würde ich denen nicht gerade anvertrauen.

--

So, ich habe gerade von Edith die Testergebnisse für ext4 erhalten. ;D Da ich aber zwischendurch mein System geupdatet hatte, wobei unter anderem die glibc auf 2.5 gehoben wurde, ist ein Vergleich mit den anderen Werten mit Vorsicht zu genießen:

ext4
bigfiles
real 6m24.283s
user 0m0.236s
sys 0m35.626s
umount
real 0m0.752s
user 0m0.004s
sys 0m0.452s
smallfiles
real 20m0.811s
user 0m3.316s
sys 0m47.663s
umount
real 0m2.440s
user 0m0.000s
sys 0m0.912s
 
Zuletzt bearbeitet:
Zurück
Oben Unten