BTRFS in Proxmox-VMs: Kluge Flexibilität oder eine CoW-auf-CoW-Falle, die nur darauf wartet zuzuschnappen?

Kennen Sie diesen Moment, kurz bevor man ein Dateisystem wählt und innehält?

Man kennt die Features durchaus. Man fragt sich eher, was das zukünftige Ich bereuen wird, und genau um diese Spannung geht es hier.

An der Oberfläche ist die Frage einfach:

Gibt es ein Problem damit, BTRFS in Proxmox-VMs zu verwenden? Ich hätte gerne CoW, Snapshots, Subvolumes. Aber ich möchte mich nicht in eine unvorhergesehene Ecke manövrieren.

Der letzte Satz erzählt die eigentliche Geschichte. Beiläufig fragt heute kaum jemand nach BTRFS. Man fragt, weil man die Features will und gleichzeitig weiß, dass das Internet voller Kriegsgeschichten ist.

Was bei dieser Diskussion tatsächlich herauskam, steht im Folgenden.

Zuerst: Was läuft auf dem Host?

Die allererste Antwort ging gar nicht auf BTRFS-Features ein, sondern stellte eine einzige Gegenfrage:

Welches Dateisystem verwenden Sie auf dem Host? Wenn es ZFS ist, werden Sie wegen Write Amplification eine schlechte Zeit haben.

Das saß. Plötzlich ging es nicht mehr um BTRFS für sich allein, sondern darum, Copy-on-Write auf Copy-on-Write zu stapeln, und da wird es pikant.

Läuft auf dem Proxmox-Host ZFS und in der VM BTRFS, verschachtelt man CoW-Verhalten. Jeder Schreibvorgang im Guest wird zu einer CoW-Operation, die der Host dann noch einmal als CoW-Operation behandelt. Der IO-Overhead kann sich dadurch schnell vervielfachen.

Jemand sagte es unverblümt:

Normalerweise ist CoW innerhalb von CoW performance-technisch eine schlechte Idee.

Das ist keine Theorie, das ist Physik.

Aber Moment, der Host ist ext4

Der ursprüngliche Verfasser stellte klar, dass auf dem Host ext4 läuft, und das änderte den Ton sofort. Gestapelt werden dann keine CoW-Systeme mehr, sondern es laufen:

• ext4 auf dem Host
• BTRFS in der VM

Das ist deutlich sauberer, und die Antwort fiel entsprechend knapp aus:

Dann habe ich keine Bedenken.

Mehr kam nicht, kein Drama und keine Weltuntergangswarnungen. Der Kontext macht eben den Unterschied.

Das Argument für BTRFS in VMs

Im Thread gab es einige starke Stimmen für BTRFS. Eine Person fasste es klar zusammen:

• Es ist für den Produktivbetrieb völlig in Ordnung.
• OpenSUSE liefert es standardmäßig aus.
• Nur BTRFS RAID5/6 vermeiden.

Der letzte Punkt ist wichtig, denn die RAID5/6-Implementierung gilt noch immer als „experimentell". RAID1 (Mirror) ist dagegen solide, und eine einzelne Disk ist auch in Ordnung.

Ein anderer Nutzer betreibt BTRFS seit über einem Jahr in Debian-VMs:

Snapshots vor Updates haben mir schon ein paar Mal den Hintern gerettet.

Das ist das Killer-Feature. Innerhalb einer VM sind BTRFS-Snapshots lächerlich praktisch. Man macht einen vor einem Upgrade, einen, bevor man an Configs herumfummelt, und einen, bevor man etwas Riskantes testet, und rollt in Sekunden zurück. Dafür braucht es weder einen Restore auf Hypervisor-Ebene noch ein vollständiges Zurücksetzen des Images, nur Zeitreise auf Dateisystemebene.

Dazu kommt die Größenänderung. Ein Kommentator wies auf etwas hin, das wirklich unterschätzt wird:

In einer VM liebe ich, dass BTRFS in beide Richtungen skalieren kann.

Dateisysteme zu vergrößern ist Alltag, sie zu verkleinern wird normalerweise hässlich. BTRFS kann beides, und in einer Lab- oder Home-Umgebung, in der sich der Storage-Bedarf ständig ändert, ist diese Flexibilität viel wert.

Das Argument gegen BTRFS

Jetzt zum emotionalen Ballast. Mehrere Nutzer meldeten sich mit Varianten derselben Geschichte:

„Ich hatte eine schlechte Erfahrung."

„Habe das ganze Array verloren."

„Konnte nach einem Update nicht mehr booten."

„Hat mich für immer abgeschreckt."

Kleine Unannehmlichkeiten waren das nicht, eher Albträume mit Wiederaufbau über mehrere Terabyte. Eine Person verlor nach einem Update ein virtualisiertes BTRFS-System und versuchte gar nicht erst, es wiederherzustellen, sondern machte einfach weiter. Eine andere verlor ein Multi-Terabyte-Array und verbrachte Wochen damit, einen Plex-Server wieder aufzubauen. So eine Erfahrung vergisst man nicht.

Auffällig ist allerdings, dass die meisten dieser Horrorgeschichten nicht von simplem Single-Disk-BTRFS in einer VM handelten. Es ging um:

• RAID-Konfigurationen
• Ältere Implementierungen
• Setups mit Edge Cases

Angst schert sich trotzdem nicht um Nuancen.

Die „Nimm einfach ext4"-Fraktion

In solchen Threads sagt immer jemand: „Ext4, außer man braucht etwas anderes."

Ein Kommentator erwähnte, dass sein großer Arbeitgeber für nicht-redundante Dateisysteme standardmäßig ext4 verwendet, weil es bewährt, langweilig und funktionstüchtig ist. Langweilig wird unterschätzt.

Eine andere Person entschied sich vor allem wegen der Backup-Konsistenz für LVM/ext4. BTRFS war dabei nicht kaputt, die Einfachheit hat schlicht gewonnen.

Da ist etwas dran. Wer CoW-Features in der VM nicht unbedingt braucht und ohnehin Snapshots auf Hypervisor-Ebene macht, kommt womöglich ganz ohne BTRFS aus.

Der versteckte Blickwinkel: Features auf Host-Ebene

Ein Kommentar räumte die ganze Feature-Liste auf einmal ab:

Man hätte keinen echten Vorteil von der VM. Snapshots und Thin Provisioning gehören eher auf die Host-Seite.

Das ist ein fairer Punkt. Läuft auf dem Proxmox-Host ZFS, hat man bereits Snapshots, Checksummen, Thin Provisioning und Kompression. Ob man dann im Guest noch BTRFS braucht, ist fraglich. Ist der Host dagegen ext4, sieht die Rechnung anders aus.

Die Dedup-Überraschung

Einer der interessanteren Kommentare kam von jemandem, der BTRFS als Backup-Ziel nutzt. Auf einer 10-TB-Platte liegen über 600 Backups, und die Platte ist erst zu 70 % voll. Der Grund ist Deduplizierung auf Blockebene.

In backup-lastigen Umgebungen, in denen sich die meisten Daten zwischen Versionen kaum ändern, kann BTRFS die Daten sehr dicht packen. Das ist keine Theorie, sondern Dichte aus der echten Welt, und so eine Effizienz lässt sich schwer ignorieren.

Also … ist es eine Falle?

Mit etwas Abstand betrachtet rät der Thread nicht zur Flucht. Er rät, den eigenen Stack zu kennen. Destilliert sieht das so aus:

Halbwegs sichere Szenarien

• Host ist ext4 oder non-CoW.
• Single-Disk-BTRFS in der VM.
• Nur RAID1/10.
• Man versteht Snapshots und Subvolumes.
• Man pflegt Backups außerhalb der VM.

Riskantere Szenarien

• ZFS auf dem Host + BTRFS im Guest.
• RAID5/6 in BTRFS.
• Kein Backup-Plan.
• Performance-sensitive Workloads auf verschachteltem CoW.

Der Bösewicht ist weniger das Dateisystem selbst als die falschen Erwartungen.

Der psychologische Teil

Die Entscheidung für BTRFS hat auch mit Persönlichkeit zu tun. Sind Sie jemand, der gern seltsame Edge Cases debuggt, bereit ist, Kernel-Logs zu lesen, problemlos Recovery-Tools lernt und ein Homelab betreibt, in dem Experimentieren zum Spaß dazugehört? Oder wollen Sie null Drama, null Überraschungen und maximale Vorhersehbarkeit?

Manche Leute werden BTRFS nie wieder vertrauen, und zwar wegen etwas, das es ihnen vor Jahren angetan hat, nicht wegen seines heutigen Zustands. Das ist legitim, Storage-Trauma gibt es wirklich.

Die Position des ursprünglichen Verfassers

Ein Detail wiegt hier schwer:

Nutze BTRFS auf meinem Homeserver seit über einem Jahrzehnt. Ein Kernel-Crash, vielleicht durch BTRFS verursacht. Abgesehen davon überhaupt keine Probleme.

Da springt niemand blind ins Neuland. Der Verfasser kennt das Dateisystem bereits, und das ändert viel, denn die größte Gefahr liegt weniger in BTRFS als in mangelnder Vertrautheit damit.

Das Urteil

Nutzt der Proxmox-Host ext4 und will man BTRFS in den Linux-VMs für Snapshots, Subvolumes, flexible Größenänderung und Lab-Experimente, läuft man nicht in eine Katastrophe. Man sollte nur:

• RAID5/6 vermeiden.
• Echte Backups pflegen.
• Kein CoW auf CoW stapeln, außer man versteht die Kosten.

Läuft auf dem Host bereits ZFS, lohnt es sich, genauer nachzudenken, denn womöglich dupliziert man Features und vervielfacht den Overhead.

Eine Ja-oder-Nein-Frage ist das also nicht. Es kommt darauf an, den eigenen Stack zu kennen. Wer BTRFS zehn Jahre lang ohne Probleme betrieben hat, manövriert sich nicht in eine Ecke, sondern wählt ein Werkzeug, mit dem er schon umzugehen weiß.