BTRFS Inside Proxmox VMs: Smart Flexibility or a CoW-on-CoW Trap Waiting to Happen?

You know that moment when you’re about to pick a filesystem and you pause? Not because you don’t know the features. But because you’re wondering what future-you is going to regret. That’s exactly the tension here . The question is simple on the surface: > Is there any problem with using BTRFS inside Proxmox VMs? I’d like CoW, snapshots, subvolumes. But I don’t want to back myself into some unforeseen corner. That last line is the real story. Because nobody asks about BTRFS casually anymore. You ask because you want power — but you also know the internet has war stories. Let’s break down what actually came out of this discussion. --- ## First: What’s the Host Running? The very first response didn’t debate BTRFS features. It asked one thing: > What filesystem are you using on the host? > If it’s ZFS, then you’ll have a bad time due to write amplification. Boom. Now we’re not talking about BTRFS in isolation. We’re talking about stacking copy-on-write on top of copy-on-write. And that’s where things get spicy. If your Proxmox host is running ZFS, and inside the VM you run BTRFS, you’re effectively nesting CoW behavior. Every write in the guest becomes a CoW operation. Then the host treats that write as another CoW operation. That can multiply IO overhead fast. And someone said it bluntly: > Normally using a CoW within a CoW is a bad idea performancewise. That’s not theoretical. That’s physics. --- ## But Wait — The Host Is ext4 The original poster clarified: Host filesystem? ext4. That changes the tone immediately. Because now we’re not stacking CoW systems. We’re running: - ext4 on the host - BTRFS inside the VM That’s much cleaner. And the response? > Then I have no concerns. That’s it. No drama. No apocalypse warnings. Context matters. --- ## The Case *For* BTRFS in VMs There were some strong pro-BTRFS voices in the thread. One person laid it out clearly: - It’s fine for production use. - OpenSUSE ships with it by default. - Just avoid BTRFS RAID5/6. That last part is important. The RAID5/6 implementation still lives in “experimental” land. But RAID1 (mirror)? Solid. Single disk? Also fine. Another user has been running BTRFS in Debian VMs for over a year: > Snapshots before updates have saved me a couple times. That’s the killer feature. Inside a VM, BTRFS snapshots are ridiculously convenient. Before an upgrade? Snapshot. About to mess with configs? Snapshot. Testing something risky? Snapshot. Roll back in seconds. No hypervisor-level restore. No full image revert. Just filesystem-level time travel. And then there’s resizing. One commenter pointed out something that’s genuinely underrated: > In a VM, I love that BTRFS can resize in both directions. Growing filesystems is common. Shrinking them? That’s where things usually get ugly. BTRFS can do both. In a lab or home environment where storage needs shift constantly, that flexibility is huge. --- ## The Case *Against* BTRFS Now let’s talk about the emotional baggage. Multiple users chimed in with variations of the same story: “I had a bad experience.” “Lost the entire array.” “Couldn’t boot after an update.” “Turned me off forever.” These weren’t mild inconveniences. These were multi-terabyte rebuild nightmares. One person lost a virtualized BTRFS system after an update and didn’t even try to recover it. Just moved on. Another lost a multi-terabyte array and spent weeks rebuilding a Plex server. That kind of experience sticks. And here’s the pattern: most of these horror stories weren’t about simple single-disk BTRFS inside a VM. They were about: - RAID configurations - Older implementations - Edge-case setups Still, fear doesn’t care about nuance. --- ## The “Just Use ext4” Crowd There’s always a voice in these threads that says: “Ext4 unless you need something else.” One commenter mentioned that their large employer defaults to ext4 for non-redundant filesystems. It’s proven. It’s boring. It works. And boring is underrated. Another person chose LVM/ext4 primarily for backup consistency. Not because BTRFS was broken. Just because simplicity won. There’s a quiet wisdom there. If you don’t absolutely need CoW features inside the VM, and you’re already doing hypervisor-level snapshots, BTRFS might be redundant. --- ## The Hidden Angle: Host-Level Features One comment cut through the feature list entirely: > You wouldn’t receive any real benefit of the VM. Snapshots and thin provisioning are more on the host side. That’s a fair point. If your Proxmox host is running ZFS, you already have: - Snapshots - Checksums - Thin provisioning - Compression Do you really need BTRFS inside the guest too? Maybe not. But if your host is ext4? That calculus changes. --- ## The Dedup Surprise One of the more interesting comments came from someone using BTRFS as a backup target. They’re storing over 600 backups on a 10TB drive and only at 70% capacity. Why? Block-level deduplication. For backup-heavy environments, especially where most data doesn’t change much between versions, BTRFS can pack things in tightly. That’s not theoretical. That’s real-world density. It’s hard to ignore that kind of efficiency. --- ## So… Is It a Trap? If you zoom out, the thread doesn’t scream “run away.” It screams “know your stack.” Here’s the distilled version: ### Safe-ish Scenarios - Host is ext4 or non-CoW. - Single-disk BTRFS inside VM. - RAID1/10 only. - You understand snapshots and subvolumes. - You maintain backups outside the VM. ### Riskier Scenarios - ZFS on host + BTRFS in guest. - RAID5/6 in BTRFS. - No backup plan. - Performance-sensitive workloads on nested CoW. The filesystem itself isn’t the villain. Misaligned expectations are. --- ## The Psychological Part Nobody Admits Choosing BTRFS is also about personality. Are you: - Comfortable debugging weird edge cases? - Willing to read kernel logs? - Fine learning recovery tools? - Running a homelab where experimentation is part of the fun? Or do you want: - Zero drama. - Zero surprises. - Maximum predictability. Some people will never trust BTRFS again. Not because of its current state — but because of something it did to them years ago. That’s valid. Storage trauma is real. --- ## The Original Poster’s Position There’s one detail that matters a lot: > Been using BTRFS on my homeserver for over a decade. One kernel crash, maybe caused by BTRFS. Apart from that, no issues whatsoever. That’s not someone blindly jumping into new territory. That’s someone who already knows the filesystem. And that changes everything. Because the real danger isn’t BTRFS. It’s unfamiliarity. --- ## The Verdict If your Proxmox host runs ext4 and you want BTRFS inside your Linux VMs for: - Snapshots - Subvolumes - Flexible resizing - Lab experimentation You’re not walking into a disaster. Just: - Avoid RAID5/6. - Keep real backups. - Don’t stack CoW on CoW unless you understand the cost. If you’re already running ZFS on the host? Think harder. You may be duplicating features and multiplying overhead. But this isn’t a “yea or nay” situation. It’s a “know your stack” situation. And if you’ve been running BTRFS for ten years without issue? You’re not backing yourself into a corner. You’re choosing the tool you already know how to wield.