Has the Qubes team ever considered the use of btrfs? https://en.wikipedia.org/wiki/Btrfs
Advertising
It's been the default root FS for Suse since 2012: https://www.linux.com/news/suse-linux-says-btrfs-ready-rock 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 situation. 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 solution. Even doing things like multi-level templates would be possible (although for root, I think package management would be problematic with more than one level). 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: https://wiki.archlinux.org/index.php/Snapper 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 comparison. :) 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 btrfs?) (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 me.) I realize such a change would be non-trivial, but it does seem like a natural way for Qubes to evolve. Thoughts? JJ -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/a7878e26a6480acbc6add8e18a73c303.webmail%40localhost. For more options, visit https://groups.google.com/d/optout.
