Re: Setting 'nodatacow' on VM image when on Btrfs

On Mon, Jul 13, 2020 at 6:20 AM Daniel P. Berrangé <berrange(a)redhat.com&gt; 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.