From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:46434) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VtI2z-0001CG-PT for qemu-devel@nongnu.org; Wed, 18 Dec 2013 09:24:29 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VtI2t-0002Zk-P6 for qemu-devel@nongnu.org; Wed, 18 Dec 2013 09:24:25 -0500 Received: from mx1.redhat.com ([209.132.183.28]:61240) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VtI2t-0002ZX-Gs for qemu-devel@nongnu.org; Wed, 18 Dec 2013 09:24:19 -0500 Date: Wed, 18 Dec 2013 14:24:11 +0000 From: "Daniel P. Berrange" Message-ID: <20131218142411.GG29247@redhat.com> References: <1384416928-3441-1-git-send-email-cyliu@suse.com> <20131115093846.GJ12545@stefanha-thinkpad.redhat.com> <20131118095746.GA16693@stefanha-thinkpad.redhat.com> <871u1ke46s.fsf@linaro.org> <20131211082954.GA31406@stefanha-thinkpad.muc.redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20131211082954.GA31406@stefanha-thinkpad.muc.redhat.com> Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [PATCH] qemu-img: set nocow flag to new file Reply-To: "Daniel P. Berrange" List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Stefan Hajnoczi Cc: Kevin Wolf , Stefan Hajnoczi , Alex =?utf-8?Q?Benn=C3=A9e?= , Chunyan Liu , qemu-devel@nongnu.org On Wed, Dec 11, 2013 at 09:29:54AM +0100, Stefan Hajnoczi wrote: > On Tue, Dec 10, 2013 at 10:23:41PM +0000, Alex Benn=C3=A9e wrote: > >=20 > > stefanha@redhat.com writes: > >=20 > > > On Mon, Nov 18, 2013 at 12:54:59PM +0800, Chunyan Liu wrote: > > >> 2013/11/15 Stefan Hajnoczi > > >>=20 > > >> > On Thu, Nov 14, 2013 at 04:15:28PM +0800, Chunyan Liu wrote: > > >> > > Set NOCOW flag to newly created images to solve performance is= sues on > > >> > btrfs. > > > > >> > This should be optional and I'm not sure it should be the defaul= t. > > >> > > > >> > Rationale: If you're on btrfs you probably expect the copy-on-wr= ite and > > >> > snapshot features of the file system. We shouldn't silently dis= able > > >> > that unless the user asks for it. > > > > > > > > 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 a= void > > > 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=3Don test.img 8G # file has NOCOW set > >=20 > > 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. >=20 > A warning could help or at least prompt users to consider switching to > nocow. IMHO such warnings are not nice - if a user does not wish to use the 'nocow' option because they want to keep the ability to use file label snapshots they should not be subjected to a warning message forever more. I suggest this is something to document in the man page instead. Daniel --=20 |: http://berrange.com -o- http://www.flickr.com/photos/dberrange= / :| |: http://libvirt.org -o- http://virt-manager.or= g :| |: http://autobuild.org -o- http://search.cpan.org/~danberr= / :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vn= c :|