2013/12/18 Daniel P. Berrange <[email protected]> > 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
-- libvir-list mailing list [email protected] https://www.redhat.com/mailman/listinfo/libvir-list
