btrfs gegen ext4, ein unerwarteter Sieger
Alle Leute sagen, btrfs sei die Zukunft. Es gibt Leute, die einen schon mitleidig angucken, wenn man ihnen sagt, dass man immer noch ext4 einsetzt, wie ich das tue. Aber ich hatte neulich einen Grund, btrfs auszuprobieren. Mit btrfs kann man nämlich Snapshots innerhalb einer verschlüsselten LV einsetzen. Mit ext4 muss man vom Cryptodevice einen Snapshot machen und dann den Snapshot gesondert aufschließen. Damit ist schroot derzeit noch überfordert (#639105).
Also habe ich mal btrfs ausprobiert und musste feststellen, dass es mindestens beim Anlegen eines chroot massiv langsamer ist als ext4. Hier meine Messergebnisse für das Anlegen eines sid-chroot mit debootstrap mit und ohne eatmydata:
| fs | eatmydata | Laufzeit |
| ext4 | nein | 4:40 |
| ext4 | ja | 4:17 |
| btrfs | nein | 8:50 |
| btrfs | ja | 8:46 |
Ich muss sagen, ich bin entsetzt. Sowohl darüber, dass btrfs so viel langsamer ist, als auch darüber, dass eatmydata so gut wie nix bringt. Habe ich etwas falsch gemacht? Braucht btrfs beim Erstellen des Dateisystems bzw. beim Einhängen desselben irgend eine magische Option, um in die gleiche Performanceregion wie ext4 zu kommen?
Testumgebung war Debian GNU/Linux sid auf einer KVM VM.
Trackbacks
No Trackbacks
Comments
Display comments as Linear | Threaded
Heavy on :
eatmydata bringt nur dann etwas, wenn die Applikation ständig fsync() macht oder die Files mit O_SYNC öffnet. Bei Standard Unix Tools wie cp, tar oder rsync ist das nicht der Fall.
Btrfs spielt seine Stärken erst bei massiv parallelen Schreibzugriffen aus. Aber auch hier gilt, dass ext4 performancemäßig schwer zu schlagen ist. Die Vorzüge von btrfs sind Features, nicht Performance.
Marc 'Zugschlus' Haber on :
Ja, aber muss die Performance Penalty -so- hoch sein?
Marc 'Zugschlus' Haber on :
Massiv parallele Schreiblast kommt aber auf den wenigsten Systemen vor. Für Arbeitsplatzrechner find ich das schon grenzwertig.
Jakob on :
Ich hab neulich Ubuntu 12.04 auf einem normalen Desktop-PC installiert und war auch überrascht davon, daß sich das System sehr lahm angefühlt hat. Alleine apt-get upgrade oder install dauerte ewig. Nach umkopieren auf ext4 lief's wie gewohnt. Also keine Benchmarks, aber gefühlt kann ich das voll bestätigen.
iq on :
gerade bei btrfs sollte man auch die genutzte Kernelversion mit in die Betrachtung ziehen. Da passiert aktuell noch ziemlich viel. Und was für ein Backing genutzt wird, spielt definitiv auch eine Rolle.
Aber ja: Performance ist nicht die allerhöchste Priorität. Theoretische Perfomance ist vorhanden, aber der Usecase muss der richtige sein. Massiv parallele Last - sprich auch genug CPU-Power in der Hinterhand
Marc 'Zugschlus' Haber on :
Der Rechner hat sich während der Tests sonst gelangweilt. Kernelversion war 3.3.6, also die zum Zeitpunkt des Tests aktuelle stabile Vanillaversion. Und was meinst Du mit Backing?
Ralf Hildebrandt on :
After almost 2 years I decided it was time to try btrfs yet another time on our squid proxies.
And, to my great amazement, this time btrfs did not fail. It "just worked". Yet I saw something strange: The machine would encounter "waves" of high load, probably induced due to periods of high IO wait. The IO activity itself didn't show any "wavy" patterns, though.
In total, btrfs would induce a 4-5 times higher IO load on the system.
Joke de Buhr on :
eatmydata bringt gewöhnlich in einem chroot nichts. in dem chroot muss die eatmydata-bibliothek installiert sein, damit eatmydata überhaupt aktiv werden kann.
da aber beim einsetzen eines chroot eatmydata noch nicht installiert ist, dann die bibliothek auch nicht aufgerufen werden.
es hilft, wenn man die eatmydata bibliothek zuvor in das chroot verzeichnis kopiert. auch muss man berücksichtigen, dass sudo nicht aufgerufen werden darf. sudo setzt LD_PRELOAD zurück.
Marc 'Zugschlus' Haber on :
Argumentation richtig, Ausgangssituation falsch. Beim Auspacken der Pakete für das chroot ist man noch nicht im chroot drin und benutzt die Libraries des Wirtssystems. Eatmydata ist dabei also wirksam.