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

[Chunyan Liu]

2013/12/18 Daniel P. Berrange <berrange at redhat.com>

> 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.
>

Thanks, Daniel! I'll rework on that.

Chunyan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20131219/8bfcef79/attachment-0001.htm>