Re: VM nocow, should VM software set +C by default?

[Justin Ossevoort <justin@internetionals.nl>]

I think in principle: No.

It is something that should be documented as advise in the VM software 
documentation. But things like storage management is the domain of the 
distribution or systems administrator.

There might be a situation where the VM software can directly use a 
btrfs filesystem for it's storage engines where it could be sensible to 
add such a thing, but in that case it's already directly managing it's 
subvolumes and can turn nodatacow on/off when appropriate.
In that case it would probably also be using some of it's higher level 
functions for snapshotting, acls and possibly metadata (and not as a 
dumb container for disk images).

So if the VM software would be controlling the filesystem directly, than 
it could be useful but would probably be better achieved using different 
options.
If the VM software is merely using it to store image files, than it 
would be up to the distribution/systems administrator to set a '+C' on 
the directory where the images will be stored (that flag were being 
inherited iirc).
A distribution could easily try marking the default images directory 
with '+C' on installation for "Joe Average" user (when he decides to do 
things differently, than that's his conscious choice). But it could also 
decide that a better default would be to use a entirely different 
subvolume for VM images, with another raid level and no compression but 
with CoW enabled by default (and thus relying on autodefrag to work).

It should simply be a matter of: Who manages the storage decides how it 
should be configured and whether not to do CoW is an aspect of 
configuration.

Regards,

	justin....

On 21-02-14 17:55, Chris Murphy wrote:
> Use case is a user who doesn't know that today xattr +C ought to be set on vm images when on Btrfs. They use e.g. Gnome Boxes, or Virtual Machine Manager (virt-manager) to configure pools, images, and VMs.
>
> If libvirt were to set +C on any containing directory configured as a pool, then any copied as well as newly created images would inherit +C. So is this the long term recommended practice, and should various VM projects be asked to build this functionality? Or will there be optimizations, such as autodefrag, that will obviate the need for +C on such VM images in the somewhat near future?
>
>
> Chris Murphy--
> To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>