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?
Das Proxmox-Boot-Dilemma: ZFS vs. BTRFS-Redundanz
Nicht, weil man die Features nicht kennt.
Sondern weil man sich fragt, was das zukünftige Ich bereuen wird.
Genau das ist die Spannung hier.
Die Frage ist an der Oberfläche 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.
Diese letzte Zeile ist die eigentliche Geschichte.
Denn niemand fragt mehr beiläufig nach BTRFS. Man fragt, weil man Power will – aber man weiß auch, dass das Internet voller Kriegsgeschichten ist.
Schauen wir uns an, was bei dieser Diskussion tatsächlich herauskam.
Zuerst: Was läuft auf dem Host?
Die allererste Antwort diskutierte nicht über BTRFS-Features.
Sie fragte nur eines:
Welches Dateisystem verwenden Sie auf dem Host? Wenn es ZFS ist, werden Sie wegen Write Amplification eine schlechte Zeit haben.
Bumm.
Jetzt reden wir nicht mehr über BTRFS isoliert. Wir reden darüber, Copy-on-Write auf Copy-on-Write zu stapeln.
Und da wird es pikant.
Wenn der Proxmox-Host ZFS ausführt und in der VM BTRFS läuft, verschachtelt man effektiv CoW-Verhalten. Jeder Schreibvorgang im Guest wird zu einer CoW-Operation. Dann behandelt der Host diesen Schreibvorgang als eine weitere CoW-Operation.
Das kann den IO-Overhead schnell vervielfachen.
Und jemand sagte es unverblümt:
Normalerweise ist CoW innerhalb von CoW performance-technisch eine schlechte Idee.
Das ist nicht theoretisch. Das ist Physik.
Aber Moment — der Host ist ext4
Der ursprüngliche Verfasser stellte klar:
Host-Dateisystem? ext4.
Das ändert den Ton sofort.
Denn jetzt stapeln wir keine CoW-Systeme. Wir betreiben:
- ext4 auf dem Host
- BTRFS in der VM
Das ist viel sauberer.
Und die Antwort?
Dann habe ich keine Bedenken.
Das war's. Kein Drama. Keine Apokalypse-Warnungen.
Kontext zählt.
Das Argument für BTRFS in VMs
Es gab im Thread einige starke Pro-BTRFS-Stimmen.
Eine Person legte es klar dar:
- 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. Die RAID5/6-Implementierung lebt noch immer im „experimentellen" Land. Aber RAID1 (Mirror)? Solide. Einzelne Disk? 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. Vor einem Upgrade? Snapshot. Kurz davor, an Configs herumzupfuschen? Snapshot. Etwas Riskantes testen? Snapshot.
In Sekunden zurückrollen.
Kein Restore auf Hypervisor-Ebene. Kein vollständiges Image-Zurücksetzen. Nur Zeitreise auf Dateisystemebene.
Und dann ist da noch 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 üblich. Sie zu verkleinern? Da wird es normalerweise hässlich.
BTRFS kann beides.
In einer Lab- oder Home-Umgebung, wo sich der Storage-Bedarf ständig ändert, ist diese Flexibilität riesig.
Das Argument gegen BTRFS
Reden wir jetzt über den emotionalen Ballast.
Mehrere Nutzer meldeten sich mit Variationen 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."
Das waren keine kleinen Unannehmlichkeiten. Das waren Multi-Terabyte-Wiederaufbau-Albträume.
Eine Person verlor nach einem Update ein virtualisiertes BTRFS-System und versuchte nicht einmal, es wiederherzustellen. Einfach weitergemacht.
Eine andere verlor ein Multi-Terabyte-Array und verbrachte Wochen damit, einen Plex-Server wieder aufzubauen.
So eine Erfahrung bleibt hängen.
Und hier ist das Muster: Die meisten dieser Horrorgeschichten handelten nicht von simplem Single-Disk-BTRFS in einer VM.
Sie handelten von:
- RAID-Konfigurationen
- Älteren Implementierungen
- Edge-Case-Setups
Trotzdem kümmert sich Angst nicht um Nuancen.
Die „Nimm einfach ext4"-Fraktion
Es gibt in solchen Threads immer eine Stimme, die sagt:
„Ext4, außer man braucht etwas anderes."
Ein Kommentator erwähnte, dass sein großer Arbeitgeber standardmäßig ext4 für nicht-redundante Dateisysteme verwendet. Es ist bewährt. Es ist langweilig. Es funktioniert.
Und langweilig ist unterschätzt.
Eine andere Person entschied sich vor allem wegen der Backup-Konsistenz für LVM/ext4. Nicht, weil BTRFS kaputt war. Einfach, weil Einfachheit gewonnen hat.
Darin steckt eine stille Weisheit.
Wenn man CoW-Features in der VM nicht unbedingt braucht und bereits Snapshots auf Hypervisor-Ebene macht, könnte BTRFS überflüssig sein.
Der versteckte Blickwinkel: Features auf Host-Ebene
Ein Kommentar durchschnitt die ganze Feature-Liste:
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.
Wenn der Proxmox-Host ZFS ausführt, hat man bereits:
- Snapshots
- Checksummen
- Thin Provisioning
- Kompression
Braucht man wirklich auch noch BTRFS im Guest?
Vielleicht nicht.
Aber wenn der Host ext4 ist? Dann ändert sich die Rechnung.
Die Dedup-Überraschung
Einer der interessanteren Kommentare kam von jemandem, der BTRFS als Backup-Ziel nutzt.
Sie speichern über 600 Backups auf einer 10-TB-Platte und sind erst bei 70 % Kapazität. Warum?
Deduplizierung auf Blockebene.
Für backup-lastige Umgebungen, besonders wenn sich die meisten Daten zwischen Versionen kaum ändern, kann BTRFS die Dinge dicht packen.
Das ist nicht theoretisch. Das ist Dichte aus der echten Welt.
Diese Art von Effizienz lässt sich schwer ignorieren.
Also … ist es eine Falle?
Zoomt man heraus, schreit der Thread nicht „lauf weg".
Er schreit „kenne deinen Stack".
Hier die destillierte Version:
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.
Das Dateisystem selbst ist nicht der Bösewicht.
Falsche Erwartungen sind es.
Der psychologische Teil, den niemand zugibt
Sich für BTRFS zu entscheiden, hat auch mit Persönlichkeit zu tun.
Sind Sie:
- Jemand, der gerne seltsame Edge Cases debuggt?
- Bereit, Kernel-Logs zu lesen?
- Jemand, der problemlos Recovery-Tools lernt?
- Jemand, der ein Homelab betreibt, in dem Experimentieren zum Spaß dazugehört?
Oder wollen Sie:
- Null Drama.
- Null Überraschungen.
- Maximale Vorhersehbarkeit.
Manche Leute werden BTRFS nie wieder vertrauen. Nicht wegen seines aktuellen Zustands – sondern wegen etwas, das es ihnen vor Jahren angetan hat.
Das ist legitim.
Storage-Trauma ist real.
Die Position des ursprünglichen Verfassers
Es gibt ein Detail, das sehr wichtig ist:
Nutze BTRFS auf meinem Homeserver seit über einem Jahrzehnt. Ein Kernel-Crash, vielleicht durch BTRFS verursacht. Abgesehen davon überhaupt keine Probleme.
Das ist nicht jemand, der blind in Neuland springt.
Das ist jemand, der das Dateisystem bereits kennt.
Und das ändert alles.
Denn die echte Gefahr ist nicht BTRFS.
Es ist Unvertrautheit.
Das Urteil
Wenn der Proxmox-Host ext4 nutzt und man BTRFS in den Linux-VMs will für:
- Snapshots
- Subvolumes
- Flexible Größenänderung
- Lab-Experimente
Läuft man nicht in eine Katastrophe hinein.
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? Genauer nachdenken. Man dupliziert möglicherweise Features und vervielfacht den Overhead.
Aber das ist keine „Ja-oder-Nein"-Situation.
Es ist eine „kenne deinen Stack"-Situation.
Und wenn man BTRFS zehn Jahre lang ohne Probleme betrieben hat?
Manövriert man sich nicht in eine Ecke.
Man wählt das Werkzeug, mit dem man bereits umzugehen weiß.