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.
Comments