Schlagwort-Archive: ext4

ext4 vs. BTRFS – mal wieder

OK, ok, zugegeben, das Thema gibt’s zu Hauf im Netz, aber ich vertraue lieber eigenen Zahlen: Was ist schneller: ext4 oder btrfs? Hintergrund ist ein Backupzwischensystem, welches große Datenmengen schnell verarbeiten muss. Die Kompression von BTRFS wäre angesichts der Kosteneinsparung durch weniger Plattenverbrauch ein schöner Bonus, aber darf nicht auf Kosten der Geschwindigkeit gehen.

Das System ist ein „Low-End“ Dualcore (Intel(R) Pentium(R) CPU G645 @ 2.90GHz) mit 16GB RAM und 4 Hitachi Deskstar 5K3000 á 2TB. Die Platten mit 5300rpm sehen zwar auf den ersten Blick etwas schwachbrüstig aus, da die Daten aber vermutlich sehr groß und entsprechend hoffentlich am Stück geschrieben werden sollte die geringe Drehzahl hoffentlich nicht wirklich ins Gewicht fallen. Das Mainboard (ASRock H77 Pro4/MVP) verfügt über zwei SATA-Controller – der Intel® H77 steuert neben 4 SATA2-Ports zusätzlich 2 Ports mit SATA3 bei, ein ASMedia ASM1061 stellt 2 zusächliche SATA3-Ports bereit. Die Platten wurden über die SATA3-Ports an beide Controller verteilt.

Die Tests liefen auf einem Arch Linux x86_64-System mit Kernel 3.11.2, als RAID kam das im Kernel enthaltene md-Framework zum Einsatz, auf die bei BTRFS integrierte RAID-Funktion verzichte ich, da ich separate Schichten für besser wartbar halte.

Erst einmal die rohen Werte der Platte: Diese lieferten im Test jeweils etwa 140MB/s sequential Read.

Erster Versuch: 1GB sequential Write, die Platten werden dabei erst mal als RAID5 genutzt, in der Hoffnung, dass die Geschwindigkeit noch ausreichend ist. Das Ergebnis ist etwas ernüchternd:

1GB Sequencial File Write
RAID5, EXT4 99MB/s
RAID5, BTRFS 134MB/s
RAID5, BTRFS (LZO) 144MB/s

BTRFS liegt zwar klar vor ext4 und auch die Kompression bringt auf Grund der gut komprimierbaren Quelle einen Geschwindigkeitsschub, insgesamt liegt die Leistung aber unter meinen Anforderungen – 144MB/s könnte die 2GBit/s Uplink grade so bewältigen, aber eigentlich hätte ich schon gerne noch etwas Reserve… Die Antwort dürfte klar sein: Da die Daten hier nur zwischengelagert werden bin ich auf das RAID5 nicht angewiesen, also RAID0 ftw – der erste Blick aufs rohe Device ist vielversprechend: 490MB/s sind ein guter Start – und was machen die Dateisysteme daraus?

RAID0, EXT4 349MB/s
RAID5, BTRFS 376MB/s
RAID5, BTRFS (LZO) 382MB/s

Viel ändert sich nicht – BTRFS mit Kompression erreicht gegenüber ext4 knapp 10% höhere Schreibraten. Die 380MB/s dürften erst bei etwa 4GBit/s uplink an ihre Grenzen stoßen – bis die fällig sind dürfte eher der Plattenplatz ausgehen. Sieger gefunden würde ich sagen: BTRFS schlägt ext4 sowohl bei Geschwindigkeit als auch beim Funktionsumfang – ob es auch die Stabilität der ext-Systeme nacheifern kann wird die Zeit zeigen.

Auf der Suche nach den inodes

So ein Linux-Server mit ext4 ist nicht so schnell klein zu bekommen – ich schaffs aber natürlich trotzdem. Auf einem meiner App-Server verabschiedete sich übers Wochenende der Datenbankserver. Diagnose eindeutig: Platte voll, 0 Bype frei. Der Auslöser ist auch schnell ausgemacht – mangels logrotate haben sich über 8GB in /var/log angesammelt. Klare Sache – Logs löschen, Dienste neustarten undnichts. Platte voll. Dafuq? Am Platz liegts nicht – dort sind die 8GB nun frei – ich vermute Böses…

# df -h /
Filesystem Size Used Avail Use% Mounted on
/dev/root 23G 14G 8.2G 62% /
# df -i /
Filesystem Inodes IUsed IFree IUse% Mounted on
/dev/root 1474560 1474560 0 100% /

Treffer versenkt – die Inodes sind voll. Aber warum? Nach kurzem Gegoogle gehe ich davon aus, dass meist eine Datei = ein Inode ist, also wird die Bash-Keule ausgepackt:

(for i in `find / -xdev -type d 2>/dev/null` ;do (echo -n `ls -1a "$i" | grep -vP "^(.|..)$" |wc -l` && echo " - $i") ;done) | sort -n

Dieser Code erzeugt eine Liste aller Ordner auf dem Device der Root-Partition – aufsteigend nach der Anzahl der Dateien sortiert. In meinem Fall ist der Schuldige relativ eindeutig:

[...]
1460 - /usr/share/man/man1
1620 - /usr/portage/metadata/cache/dev-perl
1620 - /usr/portage/metadata/md5-cache/dev-perl
1692 - /usr/portage/metadata/glsa
4554 - /usr/share/man/man3
972513 - /var/nagios/home/.maildir/new

Ich sollte mal ein paar Mails löschen -Oder auch nicht, denn…

rm *
-bash: /bin/rm: Argument list too long

also muss auch hier getrickst werden:
find ./ -exec rm {} +

2GB-Files ext4,xfs,btrfs Benchmark

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.

ext4nb

xfs

btrfs

ext4

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.