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