On Mon, Jul 20, 2020 at 12:11 PM Daniel P. Berrangé <berrange@xxxxxxxxxx> wrote: > > On Mon, Jul 13, 2020 at 08:06:22AM -0600, Chris Murphy wrote: > > On Mon, Jul 13, 2020 at 6:20 AM Daniel P. Berrangé <berrange@xxxxxxxxxx> wrote: > > > > > > On Sat, Jul 11, 2020 at 07:28:43PM -0600, Chris Murphy wrote: > > > > > > Also, the location for GNOME Boxes doesn't exist at install time, so > > > > the installer doing it with a post-install script isn't a complete > > > > solution. > > > > > > > > While Boxes can use 'qemu-img create -o nocow=on' there is an > > > > advantage of 'chattr +C' on the enclosing directory: files copied into > > > > it, as well as new files created, inherit the attribute. Meanwhile, it > > > > can't be set after the file has non-zero size. > > > > > > Boxes will use libvirt storage pools APIs to create the directory in > > > the first place. So if we add nocow support to the pool APIs, we dont > > > need to worry about per-file usage in most cases. > > > > > > > > > Is there a good way to determine whether a given filesystem supports > > > copy-on-write, other than to simply try to set the +C attribute on a > > > directory ? Ideally we would check for this feature, not check > > > whether the filesystem is btrfs, as that makes it future proof to > > > other cow supporting filesystems. > > > > It's a messy history. lsattr and chattr come from e2fsprogs. Not all > > file systems support file attributes. And not all COW file systems (or > > layers) support an option for nocow, in fact Btrfs is the only one I'm > > aware of that has it. Both as a file attribute, 'chattr +C' but also > > with a mount option 'nodatacow' - the metadata is always updated per > > copy-on-write semantic. > > > > ZFS is always copy-on-write. > > > > XFS is overwrite in place, but supports shared extents (reflink > > copies). Any overwrite to a shared extent becomes temporarily COW > > behavior. It's the same behavior on Btrfs if the file is nodatacow and > > reflinked (or snapshot). > > > > For device-mapper layered approaches (thin provisioning, vdo) I'm not > > certain whether this information is available to higher layers or can > > be inhibited. > > Given this mess, I've taken the simple option and just checked the > filesystem magic == btrfs. > > With this series: > > https://www.redhat.com/archives/libvir-list/2020-July/msg01377.html > > any application which builds storage pools in libvirt will automatically > get "nocow" attribute set on btrfs, unless they take explicit steps to > override this default. > > This will work with virt-manager and GNOME Boxes out of the box IIUC. > > Despite the fact that /var/lib/libvirt/images is created by RPM, this > should still get +C attribute set by virt-manager, and virt-install > *provided* using this syntax: > > virt-install --disk size=10 > > It won't get +C if using the explicit path: > > virt-install --disk size=10,path=/var/lib/libvirt/images/demo.img > > I'm thinking most people will use the simpler syntax, so not a big > deal. > > IOW, this should give us reasonable behaviour on btrfs out of the > box with +C set on directories, and thus auto-inherited by images. Awesome. Thanks for this work. I've updated the RFE associated with the 'btrfs by default' feature tracking bug. -- Chris Murphy
