Setting 'nodatacow' on VM image when on Btrfs

Chris Murphy lists at
Mon Jul 13 14:06:22 UTC 2020

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.

Chris Murphy

More information about the libvir-list mailing list