[libvirt] [PATCH] add --nocow option to vol-create and vol-clone

Daniel P. Berrange berrange at redhat.com
Wed Dec 18 14:30:16 UTC 2013


On Thu, Dec 05, 2013 at 11:16:42AM +0000, Daniel P. Berrange wrote:
> On Thu, Dec 05, 2013 at 06:35:12PM +0800, Chunyan Liu wrote:
> > Btrfs has terrible performance when hosting VM images, even more when the guest
> > in those VM are also using btrfs as file system. One way to mitigate 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.

Daniel
-- 
|: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org              -o-             http://virt-manager.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org       -o-       http://live.gnome.org/gtk-vnc :|




More information about the libvir-list mailing list