From: "Richard W.M. Jones" <rjones@redhat.com>
To: Maxim Levitsky <mlevitsk@redhat.com>
Cc: Kevin Wolf <kwolf@redhat.com>,
sgarzare@redhat.com, qemu-devel@nongnu.org,
qemu-block@nongnu.org, Max Reitz <mreitz@redhat.com>
Subject: Re: Bug? qemu-img convert to preallocated image makes it sparse
Date: Thu, 16 Jan 2020 16:00:44 +0000 [thread overview]
Message-ID: <20200116160044.GS3888@redhat.com> (raw)
In-Reply-To: <03ebf1f7ad780fca65dfc7486e860beb33c71d20.camel@redhat.com>
On Thu, Jan 16, 2020 at 05:38:03PM +0200, Maxim Levitsky wrote:
> How about doing write zeros without discard only in this particular case (convert to existing image)
> Basically omitting the BDRV_REQ_MAY_UNMAP flag to blk_co_pwrite_zeroes.
> It will be slow, but maybe for this particular case, it is acceptable?
I should probably say that we don't want to break the other case
(which is likely more important) where we write a sparse source to a
sparse target and want the target to contain only the union of the two
sparse maps, not fully allocated :-)
It would be fine, I think, to have a new "make this disk fully
allocated" operation. qemu-img resize could almost do it with a
request to add 0 extra bytes, but the --preallocation flag only
applies to the new space.
Rich.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-top is 'top' for virtual machines. Tiny program with many
powerful monitoring features, net stats, disk stats, logging, etc.
http://people.redhat.com/~rjones/virt-top
next prev parent reply other threads:[~2020-01-16 16:02 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-01-16 14:13 Bug? qemu-img convert to preallocated image makes it sparse Richard W.M. Jones
2020-01-16 14:37 ` Max Reitz
2020-01-16 14:50 ` Kevin Wolf
2020-01-16 14:55 ` Max Reitz
2020-01-16 15:38 ` Maxim Levitsky
2020-01-16 15:56 ` Max Reitz
2020-01-16 16:00 ` Richard W.M. Jones [this message]
2020-01-16 16:02 ` Max Reitz
2020-01-17 10:28 ` David Edmondson
2020-01-16 14:47 ` Max Reitz
2020-01-16 14:53 ` Richard W.M. Jones
2020-01-16 14:57 ` Eric Blake
2020-01-16 15:03 ` Max Reitz
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=20200116160044.GS3888@redhat.com \
--to=rjones@redhat.com \
--cc=kwolf@redhat.com \
--cc=mlevitsk@redhat.com \
--cc=mreitz@redhat.com \
--cc=qemu-block@nongnu.org \
--cc=qemu-devel@nongnu.org \
--cc=sgarzare@redhat.com \
/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.