I wonder if anyone has considered using btrfs/zfs for /rw inside an AppVM? And how would one go about implementing it?
I am perfectly fine with using LVM for underlying block storage, but features such as transparent compression and snapshots are undeniably useful. My immediate use case: compressing maildir and snapshotting between runs of imapsync. I can also see a use for zfs send/recv backups.
Btrfs is already loaded in fedora kernel, so in principle there should be no problems formatting /rw as such. Only… it’s mounted on boot, so converting it after qube is already created would be non-trivial.
Is there a better way? Or is the entire idea a pipedream?
You could attach the AppVM’s ‘private’ volume (not ‘root’ like in the linked page) to a disposable, and sudo btrfs-convert /dev/xvdi it there (instead of mounting):
Or in case it’s a brand new AppVM that has never been started yet (!!!), it would also be fine to run sudo mkfs.btrfs directly in dom0 on its ‘private’ volume device.
Note that if you ever want to enlarge the volume, Qubes OS will fail to automatically enlarge the filesystem on the enlarged volume afterwards. Currently that only works for ext2/3/4. For anything else you’d have to manually run e.g. sudo btrfs filesystem resize max /rw in the AppVM after enlarging the volume.
That (attaching LV in another VM for conversion) is exactly what I’m doing currently. I guess I should have been more specific when writing ‘non-trivial’ above.
It just feels to me that ext4 for /rw is a parameter somewhere in the qubes tools. And if it’s hard-coded currently, would making it a parameter be feasible? This way, a new qube could be created with btrfs /rw from get-go.