Dateisystemtest für flüchtig eingehängte festplatten

[MountWalker]

Dateisystemtest für flüchtig eingehängte Festplatten

Nachdem ich in einem Test vor zwei Wochen feststellte, dass Ext3 beim Schreiben meiner Musiksammlung sehr viel langsamer war als ReiserFS auf der gleichen Partition (zwischendurch neu formatiert), habe ich jetzt noch einmal genauer nachgeschaut und auch andere Dateisysteme mit in den test einbezogen.

Getestet wird ausschließlich die Schreibleistung verschiedener Dateisysteme. Die Dateisysteme werden flüchtig, ohne Eintrag in die /etc/fstab, unter /media/ eingehängt. Damit eignet sich der Test für einen Vergleich von nur zeitweise eingehängten Backup-Festplatten.

Hardware:

Gigabyte Nforce4 SLI Mainboard
2 GiB DDR400 Arbeitspeicher
Athlon64 4000+ (SanDiego mit SSE3, Einzelkern, 2,4 GHz)
Western Digital WD2500YS als Systemfestplatte (mountpunkte: / und /home)
Western Digital WD400BB als Testlaufwerk
alter G&M Wecker als Stoppuhr

Software:

Mandriva Linux 2008.1 i586/IA32
kernel-desktop-2.6.24.4-1mnb
GNOME 2.22
Terminal
bash

Dateisysteme:

Ext3
XFS
NTFS-3g
JFS
ReiserFS 3.6
Ext4 (Vorabversion)
Reiser4 (Vorabversion)

Vorgehensweise

Für den Test wird die WD400BB, eine alte 40 GiB Festplatte, mit einer einzigen Partition belegt. Nach formatieren mit dem jeweiligen Dateisystem wird die Platte kurz ausgesteckt und wieder eingesteckt, danach in /media/xy gesattelt.

Ursprünglich hatte ich nicht die Intention bei den entpsrechenden Dateisystemen "Allocate on Flush" bzw. "Delayed Allocation" also das zeitversetzte Schreiben der in den RAM geladenen Dateien abzuschalten, aber die Testresultate legen nahe, dass es stets abgeschaltet war.

Für den Test werden zuerst vier in FLAC gespeicherte Musikalben mit einem Gesamtvolumen von 2,7 GiB und Dateien der Größe 20 bis 40 MiB mit cp -r im Gnome-Terminal am Stück auf das frische Dateisystem kopiert. Danach wird der Ordner /usr/lib meines Systems, der aus über 3.000 Dateien mit einem Gesamtvolumen von ungefähr 1,7 GiB besteht, komplett auf das neue System kopiert um auch kleinere Dateien abzuschätzen. Beide Vorgänge werden mit einem externen, uralten Wecker mit Stoppuhrfunktion, der nicht durch fehlerhafte Systemausgaben beeinflusst werden kann, gemessen.

Zum Abschluss wird die Partition ausgehängt und die Zeit, die das Aushängen benötigt, gemessen, um eventuelle Verfälschungen der Schreibzeiten durch zeitversetztes Schreiben aufzudecken. Anschließend wird die Partition mit dem nächsten Dateisystem formatiert und das Testprozedere mit dem neuen Dateisystem wiederholt.

Zum Verwalten der Partitionen wird das grafische Mandriva-Kontrollzentrum verwendet. Ext4 wird mit Extents formatiert und eingehängt. Bei ReiserFS 3.6 ist Tailpacking aktiviert.


Ergebnisse:
Zeitangabe in Sekunden

ext3
2,7 GiB FLACs: 76s
1,7 GiB /usr/lib: 84s
unmount: ca. 2s

xfs
2,7 GiB FLACs: 83s
1,7 GiB /usr/lib: 223s
unmount: ca. 2s

ntfs-3g
2,7 GiB FLACs: 80s
1,7 GiB /usr/lib: 177s
unmount: ca. 2s

jfs
2,7 GiB FLACs: 75s
1,7 GiB /usr/lib: 122s
unmount: ca. 2s

reiser3.6
2,7 GiB FLACs: 87s
1,7 GiB /usr/lib: 112s
unmount: ca. 2s

ext4
2,7 GiB FLACs: 74s
1,7 GiB /usr/lib: 113s
unmount: ca. 2s

reiser4
2,7 GiB FLACs: 129s
1,7 GiB /usr/lib: 162s
unmount: Fehler

Fazit

Wie man sieht ist unmount auf allen Dateisystemen gleich schnell, was bedeutet, dass bei keinem der Dateisysteme noch Daten im RAM vom Schreiben zurückgehalten wurden. Warum Allocate on Flush bzw. Delayed Allocation nicht verwendet wurde, kann ich nicht genau sagen, da ich zum Verwalten der Partition das Mandriva Kontrollzentrum verwendete und dort, im grafischen Frontend, unter den zahlreichen Mountoptionen keine solche Option angeboten wurde. Für den Test ist es aber auch besser, da sich so die Schreibleistung besser vergleichen lässt. Das Aushängen der Reiser4-Partition schlug mit der Meldung fehl, dass es nicht eingehängt sei.

Erstaunlich ist die Performance von Ext3, obwohl es laut vielen Quellen im Internet nicht wirklich das schnellste System sein soll. Da Ext3 anderen Tests zufolge aber auch die geringste Prozessorauslastung haben soll, sähe das Ergebnis möglicherweise mit einem schnelleren Prozessor anders aus. Ich finde es jedenfalls überaus erstaunlich, dass Ext3 beim Kopieren von /usr/lib selbst schneller als ReiserFS 3.6 mit Tailpacking ist.

Die Prozessorauslastung habe ich nicht gemessen, da die GNOME-Systemüberwachung bei Anzeige der Prozessorauslastung den Prozessor selbst ganz schön belastet. Man kann das leicht feststellen, indem man die Systemüberwachung laufen lässt, ein anderes Anzeigeblatt der Systemüberwachung aktiviert und eine Weile später in das Anzeigeblatt mit der Prozessorauslastung zurückwechselt. Die Anzeige ist also nicht vertrauenswürdig.

 

[Photon]

Ui, das ist ja ein sehr interessantes Ergebnis. Wäre der Test nicht etwas für die Artikel-Sektion? Vielleicht noch mit einer zusätzlichen Messung von ntfs und fat32 unter Windows?

https://www.computerbase.de/forum/threads/artikel-oder-tests-ueber-linux.411576/

 

[MountWalker]

Naja, für nen richtigen Artikel wäre meiner Meinung der Stil zu schlecht, der Testumfang zu spezialisiert (kein Test der Leseleistung) und die Grafik zu hässlich. Ist mal was fürs Forum, das hier irgendwie fehlte - insbesondere, da andere Dateisystemtests im Web Dateisysteme auf eine Weise testen, wie sie Desktop-User nie nutzen werden.

Dateisysteme auf Windows dazu in Vergleich setzen war mir jetzt zu viel.

 

[Zedar]

Echt interssant dein Aufbau. Danke schön für die Mühe.

Tja das viel gescholtene ext3 ist in der Praxis doch nicht soo schlecht - auch wenn dein Aufbau (bei allem Respekt) vll nicht sehr repräsentativ war - lässt er doch Schlüsse zu.

Mich erstaunt auch die Performance von ntfs-3g welches ja streng genommen kein Dateisystem ist sondern nur ein Treiber für NTFS-Partitionen. Der holt einiges aus den Windows-System raus und ist gar nicht so weit entfernt von den echten FS.

 

[Krik]

Ist ja echt interessant, vorallem weil XFS so schlecht abschneidet. Ich kann mir das nicht erklären, aber XFS dürfte mit seiner Leistung eigentlich zwischen (dem vermeintlich langsamen) Ext3 und (dem vermeintlich schnelleren) ReiserFS liegen.

Ich vermute, dass da irgendwo ein Problem vorlag. Vielleicht auch sehr versteckt.

Bei mir zumindest war XFS ins Sachen Dateivorschau wesentlich schneller als Ext3. Man nehme zB ein Verzeichnis mit einigen Bildern oder Videos. Bei XFS werden die Vorschaubilder fast sofort angezeigt, Ext3 ist da wesentlich langsamer bei.

 

[aki]

Hi

Ich habe gestern auch ein wenig getestet. Ohne jetzt konkrete Messergebnisse vorzulegen kann ich sagen, dass xfs beim Erstellen von großen Dateien sehr gut war, allerdings beim Kopieren vom Portage-Tree (~125000 Dateien a ~2kb) extrem schlecht abgeschnitten hat. Bei dem Portage-Test war ReiserFS (3.6) mit Abstand am besten (fast doppelt so schnell wie Platz 2, ext3).

ext4 und reiser4 habe ich nicht getestet, eventuell hätte es da ja noch eine Überraschung gegeben.

Demnächst wollte ich nochmal block-size 2kb gegen 4kb (Standard) bei ReiserFS testen, könnte beim Portage-Tree vielleicht Vorteile bringen.

 

[MountWalker]

Naja, vielleicht ist XFS bei der Dateivorschau schneller, weil es länger beim Schreiben (der Strukturen/Metadaten) braucht - wer weiß, was da alles gemacht wird um Lesezugriffe zu beschleunigen.

Als ich mal sowas umfangreiches mit Nautilus auf Ext3 kopierte und dabei Youtube anwarf viel mir auf, dass die Schreibrate drastisch in den Keller ging (von über 30 auf ca. 15 MiB/s), also scheint die Prozessorleistung hier auch eine erhebliche Rolle zu spielen.

 

[Krik]

Ich habe im Netz mal rumgeschaut und ein paar Geschwindigkeitstests herausgesucht. Kann ja nicht sein, dass mein bevorzugtes FS so langsam ist ^^

The speed differences are significant
time /opt/linux/mysql/3.23.51/bin/mysql perftest < mysql.dump

xfs
real 12m6.739s
user 0m27.266s
sys 0m40.777s

reiserfs
real 12m39.095s
user 0m31.190s
sys 0m41.344s

ext3
real 14m58.782s
user 0m27.324s
sys 0m41.614s

Quelle

Hier hängt XFS um einiges Ext4 hinterher.

Komisch, komisch.

 

[MountWalker]

Naja, der MySQL-Test ist ja auch das, was der Grund für meinen Kurztest ist: Für Desktopo-User, die als Linux-Neueinsteiger nach dem besten FS fragen, wenig relevant. Mein Test soll eben mal zeigen, wie die Schreibleistung für Leute ist, die sowas wie MySQL nie anfassen. Ähnliches gilt für die Benchmarkprogramme im zweiten Test - wobei ich aber tar sehr praxisnah finde.

 

[Krik]

Das ist jetzt nur so ein Gedanke:
Kann es sein, dass Ext3 so schnell ist, weil die Daten nicht fragmentiert sind? Irgendwoher muss es ja kommen, dass das FS bei den Meisten lahmer erscheint als andere.

 

[MountWalker]

Naja, es gab mal einen Kurztest mit Worst-Case-Szenario für Fragmentierung auf linuxforen.de, laut dem Reiser3 und ext3 etwa gleich stark/schnell fragmentieren. Kann den grad nicht suchen, weil ich meinen dortigen Forennamen vergessen habe und jenes Board einem, warum auch immer, nicht erlaubt die Suchfunktion zu nutzen, ohne eingeloggt zu sein.

P.S.
Reiser und Ext fragmentierten laut dem Test damals aber glaube ich ca. zehn mal so stark/schnell, wie XFS - und NTFS zehn mal stärker/schneller als Ext/Reiser.

 

[karuso]

allgemein würde ich xfs nicht auf externen datenträgern verwenden. durch das verzögerte schreiben(dateien werden so lange wie möglich im ram gehalten) kann es sein dass bei einem plötzlichen entfernen der platte die daten noch nicht geschrieben wurden.
für solche dinge habe ich immer ext2/3 genutzt - relativ einfaches system das alle distris problemlos lesen können. hier würde sich bei xfs ein weiteres problem zeigen: xfs, bzw das journal ist prozessorabhängig - bevor eine andere architektur das dateisystem lesen kann muss das journal geleert werden. beim wechsel vom macbook(x86) zum powerbook(ppc) müsste man jedes mal xfs_repair ausführen.
vorteile verbucht xfs bei der suche nach dateien bzw dem aufrufen dieser. hier ist xfs sehr performant(was sich auch an e-laurins bildvorschau zeigt). xfs ist eben für extreme ausgelegt; riesige datenmengen die durchsucht werden müssen, parallele bearbeitung der zugriffe und schneller aufruf.

 

[Krik]

Hehe und genau deshalb verwende ich es
So oft schiebt man ja nun keine größeren Daten durch die Gegend. Die Zugriffszeit ist da wichtiger (zumindest für mich).

 

[MountWalker]

Ich hab jetzt mal, nachdem sich meine Mutter darüber beschwerte, dass ihr PC (Duron-Morgan 1,2 GHz, Nforce2-Ultra400, 1 GiB RAM, Radeon9700, Maxtor 30 GiB Platte, Mandriva 2008.1, / ca. 10 GiB, Swap 2 GiB, /home ca. 28 GiB) schon immer sehr lange zum starten gebraucht hat, bei ihr (mit Backup und Wiedereinspielen ihres gesamten Home-Verzeichnisses) die Home-Partition von Ext3 auf ReiserFS geändert. Bei meinem eigenen PC hatte ich damals gar keinen Unterschied bei der Startzeit bemerkt - aber ich hab auch nicht drauf geachtet.

Mit der alten Formatierung / ReiserFS 3.6 und /home Ext3 brauchte ihr PC inklusive Autologin auf Gnome bis das Panel vollständig geladen war 2:39 min, dabei brauchte er über 20 sec zum Prüfen ob genügend freier Speicherplatz da war (/home fast leer). Nach einer Neuinstallation des Systems (war mir jetzt unkomplizierter, als herauszufinden, wie ich ohne Neuinstallation das Format der /home-Partition ändern könnte) und Formatierung beider partitionen (/ und /home) in ReiserFS 3.6 braucht das System nur noch 1:33 Minuten Startzeit incl. Autologin auf Gnome -

die Startzeit ist über eine Minute kürzer, sie beträgt nur noch 59 % der ursprünglichen Startzeit.

Vielleicht hängt das mit dem "langsamen" Prozessor zusammen, so dass also, anders als ich vorher annahm, Ext3 deutlich mehr Prozessorleistung verpulvert als ReiserFS 3.6 oder ext3 ist generell deutlich langsamer beim Lesen.

 

[Sensei21]

die Startzeit ist über eine Minute kürzer, sie beträgt nur noch 59 % der ursprünglichen Startzeit.

mag ja sein, aber es wird in nächster zeit noch besser kommen

zur zeit prüft reiserfs bei jedem start das gesamte log, das soll sich in zukunft ändern & ähnlich wie bei den >=ext-3* dateisystemen werden, dass nur z.B. jedes 30. mal geprüft wird

hab momentan den genauen link nicht, dürfte aber auf lkml.org oder der reiserfs newsgroup stehen ...

das wird aber langsam etwas zu offtopic

in >=2.6.25 wurden übrigens einige gröbere fehler in reiser4 ausgebessert, jetzt läuft es deutlich runder

benchmarks wie bonnie und/oder nur hin- und herschaufeln von dateien sind für mich eigentlich nicht der diskussion wert, da man nicht den waren wert / die leistung des fs sieht,

wenn ihr viel zu kompilieren habt oder viel mit programmen (u.a. das starten ), dann ist der ideale test das dateisystem auf der /root partition zu haben, dadurch sieht man dann wie das fs in sämtlichen situationen insgesamt abschneidet ...

 

[MountWalker]

...
benchmarks wie bonnie und/oder nur hin- und herschaufeln von dateien sind für mich eigentlich nicht der diskussion wert, da man nicht den waren wert / die leistung des fs sieht, ...

Naja, ob der normale Desktoppy oder Homy, der Nicht-Tecchie gewillt ist erstmal nacheinander mehrere Dateisysteme durchzuprobieren um zu wissen, was für ihn das beste ist? Entweder er frisst und stirbt die Vorauswahl oder er geht ins WWW und schaut nach Entscheidunghilfen, die natürlich schon irgendwie begründet sein sollten. Mich hats als Homy jedenfalls stets genervt, dass man entweder nur Larifari liest, wonach ext3 "nicht so schnell" sei, ohne Erklärung, wann und wie es langsam ist, oder mit Benchmarks abgespeist wird, die Sachen testen, die ich nie nutzen werde.

P.S.
Geeks waren noch nie "meine Zielgruppe".

 

[Sensei21]

war das jetzt ein kompliment oder nur eine nebenbemerkung ?

um nochmal auf den test zurückzukommen: mich hat es schon sehr gewundert, dass die reiser* dateisystem so schlecht abgeschnitten haben & ext3 so schnell gearbeitet hat, vielleicht waren ein paar schöne performance-patches im inoffiziellen mandriva-kernel dabei

jedenfalls lassen sich die kopiervorgänge mit noatime,nodiratime um einiges beschleunigen (data-safe); wenn die daten-sicherheit keine allzu große rolle spielt und/oder man gerade viel hin- und herschaufeln muss kann man auch noch data=writeback,commit=120 verwenden, dann lässt sich 20-50 % mehr leistung herausholen

 

[MountWalker]

War ne Nebenbemerkung um zu unterstreichen, für wen der Test gedacht ist. Aber wenns als kompliment ankommt, ists mir auch recht.

Ich hab mal nen Screenshot von den im Test verwendeten Mountoptionen für Ext3 aus dem grafischen Konfigurationswerkzeug gemacht, liegt im Anhang. Bei den anderen Dateisystemen siehts ungefähr genauso aus.

P.S.
Das Bild im Firefox/Opera/Safari in einem neuen tab öffnen, da ComputerBase hier wiedermal eine megatechnologische Superfunktion integriert hat, die das Ding sonst einfach so skaliert über die Website legt, was deshalb so scheiße ist, weil beim Skalieren nicht interpoliert wird und man nichts lesen kann. Irgendwie scheint der Webmaster hier in letzter Zeit an Featureitis zu leiden.