From: "Richard W.M. Jones" <rjones@redhat.com>
To: Kevin Wolf <kwolf@redhat.com>
Cc: qemu-devel@nongnu.org, qemu-block@nongnu.org
Subject: Re: [Qemu-devel] qemu-img create doesn't always replace the existing file
Date: Tue, 8 Nov 2016 14:16:43 +0000 [thread overview]
Message-ID: <20161108141643.GB11243@redhat.com> (raw)
In-Reply-To: <20161108140524.GF5088@noname.str.redhat.com>
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
prev parent reply other threads:[~2016-11-08 14:16 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-11-08 10:58 [Qemu-devel] qemu-img create doesn't always replace the existing file Richard W.M. Jones
2016-11-08 14:05 ` Kevin Wolf
2016-11-08 14:16 ` Richard W.M. Jones [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20161108141643.GB11243@redhat.com \
--to=rjones@redhat.com \
--cc=kwolf@redhat.com \
--cc=qemu-block@nongnu.org \
--cc=qemu-devel@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.