btrfs gegen ext4, ein unerwarteter Sieger

Sunday, May 20. 2012

Posted by Marc 'Zugschlus' Haber in Freie Software at 10:39 | Comments (9) | Trackbacks (0)

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.

Defined tags for this entry: btrfs, eatmydata, ext4, filesystems, linux

Related entries by tags:

Random Entry: Bestandskunden sind Dreck
< Elektrik, Leitungen, Kabelschächte | Die Zeiten ändern sich >

Mark as read

Trackbacks

Trackback specific URI for this entry

No Trackbacks

Comments

Display comments as (Linear | Threaded)

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.

Comment (1)

#1 Heavy on 2012-05-20 17:37 (Reply)

Ja, aber muss die Performance Penalty -so- hoch sein?

Comments (4)

#1.1 Marc 'Zugschlus' Haber (Homepage) on 2012-05-22 14:22 (Reply)

Massiv parallele Schreiblast kommt aber auf den wenigsten Systemen vor. Für Arbeitsplatzrechner find ich das schon grenzwertig.

Comments (4)

#1.2 Marc 'Zugschlus' Haber (Homepage) on 2012-05-23 09:20 (Reply)

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.

Comment (1)

#2 Jakob on 2012-05-21 00:59 (Reply)

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

Comment (1)

#3 iq on 2012-05-21 13:59 (Reply)

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?

Comments (4)

#3.1 Marc 'Zugschlus' Haber (Homepage) on 2012-05-22 14:23 (Reply)

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.

Comment (1)

#4 Ralf Hildebrandt (Homepage) on 2012-05-21 19:40 (Reply)

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.

Comment (1)

#5 Joke de Buhr on 2012-06-20 00:08 (Reply)

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.

Comments (4)

#5.1 Marc 'Zugschlus' Haber (Homepage) on 2012-06-20 08:21 (Reply)

Add Comment

Name
Email
Homepage
In reply to
Comment	HTML-Tags will be converted to Entities. Enclosing asterisks marks text as bold (word), underscore are made via _word_. Pavatar, Pavatar, Pavatar, Pavatar, Pavatar, Pavatar author images supported. To prevent automated Bots from commentspamming, please enter the string you see in the image below in the appropriate input box. Your comment will only be submitted if the strings match. Please ensure that your browser supports and accepts cookies, or your comment cannot be verified correctly. Enter the string from the spam-prevention image above:
	Remember Information?

btrfs gegen ext4, ein unerwarteter Sieger

Zugschlusbeobachtungen

Sunday, May 20. 2012

btrfs gegen ext4, ein unerwarteter Sieger

IPv6 Check

Quicksearch

Blog Administration

Categories

Recently added

Comments

Syndicate This Blog

Show tagged entries

Template dropdown

Technorati

Twitter Timeline

Static Pages