Has the Qubes team ever considered the use of btrfs?
It's been the default root FS for Suse since 2012:
While reading about its features (and using it) it seems like it would be
especially well-suited as a base for Qubes, giving unlimited snapshots,
nested overlays/unions (seeds), rollbacks, subvolumes, sparse files, plus
easy adding/removing of disks, raid, space balancing, and greater
reliability (with the raid and checksum of metadata/data). A win/win
It would make the template implementation a lot simpler, faster, and more
flexible. Instead of .img files, you'd just have subvolumes (and use of
seeds/unions). It seems like a more elegant, flexible, and extensible
Even doing things like multi-level templates would be possible (although
for root, I think package management would be problematic with more than
Cloning a given template or an appvm would be instant and require zero
disk space (due to the innate copy-on-write nature of btrfs) rather than
taking many minutes and doubling the disk usage. The only space used by a
cloned template/vm would be what was eventually modified. Booyeah.
If used as a rootfs, even without any further template integration, the
deduplication feature should automatically bring the same disk savings.
It also offers self-healing, online checking/shrinking/growth,
"deduplication" of blocks with the same content, ..., the list goes on.
The related btrfs support utility "Snapper" also seems like it would fit
in very nicely with Qubes:
Suse automatically creates a snapshot whenever packages are installed, so
it's easy to rollback any undesired changes. Again, that would be a great
feature for templates.
You can even convert an ext4 system to btrfs, and keep both available,
since btrfs keeps the data blocks in a compatible way and puts it metadata
in other unused space. It makes the existing ext4 metadata a separate
btrfs subvolume, you can later delete if you choose--very slick. (Or
similarly, you can revert to ext4-only as easily.)
I'm starting to use BTRFS for all my non-root/non-user devices, and I'm
loving it. The private.img/volatile.img structure seems primitive by
I realize the ext* code is probably considered more mature, stable, and
safe for dom0, but btrfs seems to have been put through its paces quite
well over the years (and I'm sure ext4 itself has been having a lot of
code changes over the years, possibly making it no more secure than
(I haven't checked if the Qubes install allows it as an option for root.
Even if it does allow its basic use, going further and leveraging the
seed/subvolume/snapshot for templates/appvms is the more exciting part to
I realize such a change would be non-trivial, but it does seem like a
natural way for Qubes to evolve.