Setting 'nodatacow' on VM image when on Btrfs

Daniel P. Berrangé berrange at
Mon Jul 20 18:11:30 UTC 2020

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> 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:

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

IOW, this should give us reasonable behaviour on btrfs out of the
box with +C set on directories, and thus auto-inherited by images.

|:      -o- :|
|:         -o-   :|
|:    -o- :|

More information about the libvir-list mailing list