On Feb 25, 2014, at 2:16 AM, Justin Ossevoort <jus...@internetionals.nl> wrote:
> 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. No, that's a recipe for users having a chaotic experience. Either the VM managing application needs to set +C on image files, or the file system needs to be optimized for this use case. Consider the Gnome Boxes user. They're not in a good position to do this themselves, and each distro doing this causes fragmented experience. It's better if the application developer (Gnome Boxes, VMM) or possibly libvirt to set +C on VM images; or as a general purpose file system for it to be optimized for this use case. Either way it leaves the end user out of what amounts to esoteric configuration. > 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. I don't expect VM's to use subvolumes directly, instead of image files (qcow2, raw, vmdk, etc) for a while, and also I'm not sure if there's enough separation between VMs, or VM and host sharing what is really one file system. If there's any possibility a misbehaving VM could corrupt the file system and not merely its own tree, then it's unlikely a best practice. Chris Murphy -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
