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