It's generally recommended by upstream Btrfs development to set
'nodatacow' using 'chattr +C' on the containing directory for VM
images. By setting it on the containing directory it means new VM
images inherit the attribute, including images copied to this
location.
But 'nodatacow' also implies no compression and no data checksums.
Could there be use cases in which it's preferred to do compression and
checksumming on VM images? In that case the fragmentation problem can
be mitigated by periodic defragmentation.
Is this something libvirt can and should do? Possibly by default with
a way for users to opt out?
Another option is to have the installer set 'chattr +C' in the short
term. But this doesn't help GNOME Boxes, since the user home isn't
created at installation time.
Three advantages of libvirt awareness of Btrfs:
(a) GNOME Boxes Cockpit, and other users of libvirt can then use this
same mechanism, and apply to their VM image locations.
(b) Create the containing directory as a subvolume instead of a directory
(1) btrfs snapshots are not recursive, therefore making this a
subvolume would prevent it from being snapshot, and thus (temporarily)
resuming datacow.
(2) in heavy workloads there can be lock contention on file
btrees; a subvolume is a dedicated file btree; so this would reduce
tendency for lock contention in heavy workloads (this is not likely a
desktop/laptop use case)
(c) virtiofs might be able to take advantage of btrfs subvolumes.
(This is a partial rewrite of
https://bugzilla.redhat.com/show_bug.cgi?id=1855000)
Thanks,
--
Chris Murphy
