Gibt es bei BTRFS irgendetwas wichtiges zu beachten?
Ich persönlich will von btrfs wieder wegkommen, es nicht kompatibel mit meiner Anwendung:
Bist du ein User wie ich, der die Platte immer ziemlich voll hat und ab und auch mal komplett ausfüllt, dann rate ich davon ab, da btrfs nur funktioniert wenn es ein paar Prozente zum rumscheffeln hat. Bei mir läuft der entsprechende Kernelthread dann auch auf 100%, wenn ich mal wieder keinen Plattenplatz habe, was essentiell jegliches I/O massiv ausbremst.
Ausserdem haben einige Anwendungen andere Annahmen über die Konsistenzgarantien vom Dateisystem als das was btrfs bietet.
Zitat
Something to note here is that while btrfs’s semantics aren’t inherently less relaible than ext3/ext4, many more applications corrupt data on top of btrfs because developers aren’t used to coding against filesystems that allow directory operations to be reordered (ext2 is perhaps the most recent widely used filesystem that allowed that reordering).
http://danluu.com/file-consistency/
Ich kann es auf meinem btrfs fast zuverlässig reproduzieren, dass wenn bei mir die Platte voll ist, Firefox seine Cookie-Datei danach zerschossen ist.
Das sind noch zu wenig verwirrende Layer, pack doch noch ein bisschen md-RAID und nochmal ne Paritionstabelle dazwischen.
Unter Arch würde ich davon abraten, btrfs direkt im LUKS zu fahren. Erstens gibt es dann kein verschlüsseltes Swap, denn waren die mkinitcpio Hooks vor einem Jahr nicht darauf ausgelegt zwei Container mit einem Schlüssel zu entschlüsseln. Ausserdem bin ich mir nicht sicher, ob die Hooks mit den Subvolumes automatisch klarkommen.