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

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.

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.