From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([2001:4830:134:3::10]:55686)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <rjones@redhat.com>) id 1c47Co-0001nF-DL
	for qemu-devel@nongnu.org; Tue, 08 Nov 2016 09:16:58 -0500
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <rjones@redhat.com>) id 1c47Cn-0005ch-90
	for qemu-devel@nongnu.org; Tue, 08 Nov 2016 09:16:54 -0500
Date: Tue, 8 Nov 2016 14:16:43 +0000
From: "Richard W.M. Jones" <rjones@redhat.com>
Message-ID: <20161108141643.GB11243@redhat.com>
References: <20161108105840.GF27578@redhat.com>
	<20161108140524.GF5088@noname.str.redhat.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20161108140524.GF5088@noname.str.redhat.com>
Subject: Re: [Qemu-devel] qemu-img create doesn't always replace the
 existing file
List-Id: <qemu-devel.nongnu.org>
List-Unsubscribe: <https://lists.nongnu.org/mailman/options/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.nongnu.org/archive/html/qemu-devel/>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <https://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Kevin Wolf <kwolf@redhat.com>
Cc: qemu-devel@nongnu.org, qemu-block@nongnu.org

On Tue, Nov 08, 2016 at 03:05:24PM +0100, Kevin Wolf wrote:
> [ Cc: qemu-block ]
> 
> Am 08.11.2016 um 11:58 hat Richard W.M. Jones geschrieben:
> > When using 'qemu-img create', if the file being created already
> > exists, then qemu-img tries to read it first.  This has some
> > unexpected effects:
> > 
> > 
> > $ rm test.qcow2 
> > $ qemu-img create -f qcow2 -o compat=1.1,preallocation=off test.qcow2 1G
> > Formatting 'test.qcow2', fmt=qcow2 size=1073741824 compat=1.1 encryption=off cluster_size=65536 preallocation=off lazy_refcounts=off refcount_bits=16
> > $ du -sh test.qcow2 
> > 196K test.qcow2
> > 
> > 
> > $ rm test.qcow2 
> > $ qemu-img create -f qcow2 -o compat=1.1,preallocation=falloc test.qcow2 1G
> > Formatting 'test.qcow2', fmt=qcow2 size=1073741824 compat=1.1 encryption=off cluster_size=65536 preallocation=falloc lazy_refcounts=off refcount_bits=16
> > $ qemu-img create -f qcow2 -o compat=1.1,preallocation=off test.qcow2 1G
> > Formatting 'test.qcow2', fmt=qcow2 size=1073741824 compat=1.1 encryption=off cluster_size=65536 preallocation=off lazy_refcounts=off refcount_bits=16
> > $ du -sh test.qcow2 
> > 256K test.qcow2            # would expect this to be the same as above
> 
> For me it's actually even more:
> 
> $ du -h /tmp/test.qcow2 
> 448K    /tmp/test.qcow2
> 
> However...
> 
> $ ls -lh /tmp/test.qcow2 
> -rw-r--r--. 1 kwolf kwolf 193K  8. Nov 15:00 /tmp/test.qcow2
> 
> So qemu-img can't be at fault, the file has the same size as always.
> 
> Are you using XFS? In my case I would have guessed that it's probably
> some preallocation thing that XFS does internally. We've seen this
> before that 'du' shows (sometimes by far) larger values than the file
> size on XFS. That space is reclaimed later, though.

Yes I am, and indeed this looks like a filesystem artifact and not
a problem with qemu-img.

Thanks,

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
libguestfs lets you edit virtual machines.  Supports shell scripting,
bindings from many languages.  http://libguestfs.org