Setting 'nodatacow' on VM image when on Btrfs

[Chris Murphy]

On Mon, Jul 20, 2020 at 12:11 PM Daniel P. Berrangé <berrange at redhat.com> 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 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.


Awesome. Thanks for this work. I've updated the RFE associated with
the 'btrfs by default' feature tracking bug.

-- 
Chris Murphy