On Tue, Dec 10, 2013 at 10:23:41PM +0000, Alex Bennée wrote: > > stefa...@redhat.com writes: > > > On Mon, Nov 18, 2013 at 12:54:59PM +0800, Chunyan Liu wrote: > >> 2013/11/15 Stefan Hajnoczi <stefa...@gmail.com> > >> > >> > On Thu, Nov 14, 2013 at 04:15:28PM +0800, Chunyan Liu wrote: > >> > > Set NOCOW flag to newly created images to solve performance issues on > >> > btrfs. > <snip> > >> > This should be optional and I'm not sure it should be the default. > >> > > >> > Rationale: If you're on btrfs you probably expect the copy-on-write and > >> > snapshot features of the file system. We shouldn't silently disable > >> > that unless the user asks for it. > <snip> > > > > 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. > > > > Please make it a .bdrv_create() option which is off by default to avoid > > breaking existing users' workflows/scripts. The result should be > > something like: > > > > $ qemu-img create test.img 8G # file has NOCOW cleared > > $ qemu-img create -o nocow=on test.img 8G # file has NOCOW set > > I agree we shouldn't break existing work flows. I wonder if it would OK > for qemu-img to issue a warning (when not --quiet) when it detects > creation of an image on a partition where performance may not be as > expected due to COW behaviour.
A warning could help or at least prompt users to consider switching to nocow. Stefan
