Da ich derzeit meinen Server aufrüste stellt sich unter anderem die Frage nach dem Dateisystem. Für Root & Homes habe ich bereits auf anderen Systemen ext4 seit längerem im Einsatz, für meine Video-Partition war ich aber nicht ganz sicher. Auf dieser liegen Rohdaten z.B. meines Podcasts oder von Konvertieren von VHS etc, also viele große Dateien. Bisher durfte sich xfs um die Dateien kümmern, mit ext4 soll aber nun xfs Konkurrenz bekommen haben. Da die meisten Tests recht allgemein gehalten waren musste ein eigenes Script ran. Zusätzlich zu xfs und ext4 habe ich noch ext4 mit aktivem „nobarrier“ sowie btrfs getestet. System ist ein AMD Opteron 2358 (Quad 2,4GHz) mit 4GB RAM, Storage ein 3-Disk RAID5 mit ~235MB/s Durchsatz bei hdparm -t.
I/O-Performance
Erst ein Blick auf lesen, schreiben, simultanen Lese-/Schreibzugriffen und löschen. Datenquelle fürs schreiben war ein tmpfs, lesen ging auf /dev/null:
write | read | rw | del | |
ext4 | 84,4 | 114,0 | 49,3 | 1.941,5 |
ext4nb | 83,1 | 197,0 | 29,9 | 10.077,5 |
xfs | 54,6 | 207,0 | 29,9 | 109.462,1 |
btrfs | 86,0 | 200,0 | 51,9 | 2.006,6 |
Wie man sieht hat bei Schreibzugriffen btrfs die virtuelle Nase knapp vor den ext4-Varianten, xfs ist gut ein Fünftel langsamer. Wenns ums Lesen geht kann xfs deutlich punkten, auch wenn btrfs hier knapp dran ist. Der Ausrutscher von ext4 mit Barriers mach für mich zwar keinen Sinn, war aber reproduzierbar. Bei parallelen Zugriffen spielt btrfs wieder sein Asse aus, ext4 mit Barriers ist aber knapp dahinter. Xfs leidet hier unter der schlechten Schreibperformance, Ext4nb – tja, gute Frage… Beim Löschen zahlt sich das XFS-Design wieder aus: Löschen geht fast zehn mal schneller als bei ext4nb – mit Barriers macht ext4 jedoch eine eben so schlechte Figur wie btrfs.
Schaut man nur auf die (theoretischen) Zahlen zeigt sich btrfs schon jetzt als klarer Sieger, jedoch ist es noch in der Entwicklungsphase und kann entsprechend zu Stabilitätsproblemen führen. XFS hält sich bei großen Dateien noch knapp vor EXT4 ohne Barriers, mit Barriers ist die (hier) mangelhafte Lesegeschwindigkeit nicht entschuldbar.
Praxis
Da ich noch ein paar Sachen zu schneiden Habe einfach mal ein Praxistest: Jedes Dateisystem bekommt eine Rohdatei (2GB +/- paar MB) von einem tmpfs drauf kopiert, diese wird erst geprüft (md5sum) in ein anderes Containerformat konvertiert, danach wird von der neu erstellten Datei erneut eine MD5-Summer erstellt, im Anschluss greift eine vorbereitete Schnittliste und speichert eine geschnittene Version. Zum Abschluss wird die Quell- und Zwischendatei gelöscht. Alles nahezu reine I/O-Operationen, da nichts umcodiert werden muss.
Dateisystem | Zeit in Sec. |
---|---|
171 | |
174 | |
187 | |
199 |
Wie man sieht kann btrfs seinen theoretisch deutlichen Vorsprung nicht halten und fällt auf Platz 3 – hier fehlen wohl noch die nötigen Optimierungen um in der Praxis die guten I/O-Werte auszuspielen. ext4nb schafft es auf den ersten Platz, dicht gefolgt von xfs. Ext4 mit aktiven Barriers, welche auf druck der Community nun Standard sind, liegt auch in diesem Test abgeschlagen auf dem letzten Platz.
Fazit
Wenn es um große Dateien geht sind ext4 ohne Barriers und XFS nahezu gleich auf. XFS ist jedoch fast 14 Jahre älter und ist daher als stabiler anzusehen, zumdem nutzt es vorhandenen Speicherplatz besser aus. Die technischen Grenzen der Dateisysteme sind für aktuelle Rechner eher uninteressant, jedoch unterstützt nur ext4 das nachträgliche verkleinern einer Partition.
Ich für meinen Teil werde für große Dateien damit bei XFS bleiben.
adlerweb XFS könntest du auch noch mit „nobarrier“ durchjagen. Theoretisch sollte das einiges bringen, zumindest bei unseren Tests damals.