Setting 'nodatacow' on VM image when on Btrfs

[Daniel P. Berrangé]

On Sat, Jul 11, 2020 at 07:28:43PM -0600, Chris Murphy wrote:
> On Fri, Jul 10, 2020 at 6:16 AM Daniel P. Berrangé <berrange at redhat.com> wrote:
> >
> > On Thu, Jul 09, 2020 at 02:15:50PM -0600, Chris Murphy wrote:
> > > On Thu, Jul 9, 2020 at 12:27 PM Daniel P. Berrangé <berrange at redhat.com> wrote:
> > > Good point. I am open to suggestion/recommendation by Felipe Borges
> > > about GNOME Boxes' ability to do installs by injecting kickstarts. It
> > > might sound nutty but it's quite sane to consider the guest do
> > > something like plain XFS (no LVM). But all of my VM's are as you
> > > describe: guest is btrfs with the checksums and compression, on a raw
> > > file with chattr +C set.
> >
> > GNOME Boxes / virt-install both use libosinfo for doing the automated
> > kickstart installs. In the case of Fedora that's driven by a template
> > common across all versions. We already have to cope with switch from
> > ext3 to ext4 way back in Fedora 10. If new Fedora decides on btrfs
> > by default, we'll need to update the kickstart to follow that
> > recmmendation too
> >
> > https://gitlab.com/libosinfo/osinfo-db/-/blob/master/data/install-script/fedoraproject.org/fedora-kickstart-jeos.xml.in#L80
> 
> Understood.
> 
> 
> > > For lives it's rsync today.  I'm not certain if rsync carries over
> > > file attributes. tar does not. Also not sure if squashfs and
> > > unsquashfs do either. So this might mean an anaconda post-install
> > > script is a more reliable way to go, since Anaconda can support rsync
> > > (Live) and rpm (netinstall,dvd) installs. And there is a proposal
> > > dangling in the wind to use plain squashfs (no nested ext4 as today).
> >
> > Hmm, tricky, so many different scenarios to consider - traditional
> > Anaconda install, install from live CD, plain RPM post-install,
> > and pre-built disk image.
> 
> 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.

Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|