Setting 'nodatacow' on VM image when on Btrfs

[Daniel P. Berrangé]

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 at redhat.com> 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.

Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|