2013/12/18 Daniel P. Berrange <berrange@redhat.com>
On Thu, Dec 05, 2013 at 06:35:12PM +0800, Chunyan Liu wrote:
Btrfs has terrible performance when hosting VM images, even more when
in those VM are also using btrfs as file system. One way to mitigate
On Thu, Dec 05, 2013 at 11:16:42AM +0000, Daniel P. Berrange wrote: the guest this bad
performance is to turn off COW attributes on VM files (since having copy on write for this kind of data is not useful).
According to 'chattr' manpage, NOCOW could be set to new or empty file only on btrfs, so this patch tries to add a --nocow option to vol-create functions and vol-clone function, so that users could have a chance to set NOCOW to a new volume if that happens to create on a btrfs like file system.
What effect / impact does setting this flag have from a functional POV ? Why would we not just unconditonally enable it on btrfs so it was fast "out of the box" ? I'm loathe to add a btrfs-specific flag to our public API.
Quoting from the qemu-devel thread on the same subject:
When the NOCOW attribute is set on a file, reflink copying (aka file-level snapshots) do not work:
$ cp --reflink test.img test-snapshot.img
This produces EINVAL.
It is a regression if qemu-img create suddenly starts breaking this standard btrfs feature for existing users.
So as with QEMU, I don't think libvirt can do something which could break existing users of brtfs in this way. So this would have to be an opt-in of some kind.
We already have a way to express "features" for storage volumes in the XML description. We could use this to express a 'nocow' feature. This is preferrable to an API flag, since this would let a user query XML for an existing volume to discover if it had 'nocow' or not.
Thanks, Daniel! I'll rework on that. Chunyan