From: Stefan Hajnoczi <stefanha@gmail.com>
To: Fam Zheng <famz@redhat.com>
Cc: qemu-devel@nongnu.org, Kevin Wolf <kwolf@redhat.com>,
qemu-block@nongnu.org, Max Reitz <mreitz@redhat.com>
Subject: Re: [Qemu-devel] [Qemu-block] [PATCH v3] block: Turn on "unmap" in active commit
Date: Fri, 30 Sep 2016 15:00:20 +0100 [thread overview]
Message-ID: <20160930140020.GK24982@stefanha-x1.localdomain> (raw)
In-Reply-To: <20160930021205.GC29760@lemon>
[-- Attachment #1: Type: text/plain, Size: 2583 bytes --]
On Fri, Sep 30, 2016 at 10:12:05AM +0800, Fam Zheng wrote:
> On Thu, 09/29 13:41, Stefan Hajnoczi wrote:
> > On Tue, Sep 27, 2016 at 07:14:52PM +0800, Fam Zheng wrote:
> > > We already specified BDRV_O_UNMAP when opening images in 'qemu-img
> > > commit', but didn't turn on the "unmap" in the active commit job. This
> > > patch fixes that so that zeroed clusters in top image can be discarded
> > > which is desired in the virt-sparsify use case, where a temporary
> > > overlay is created and fstrim'ed before commiting back, to free space in
> > > the original image.
> > >
> > > This also enables it for block-commit.
> > >
> > > Signed-off-by: Fam Zheng <famz@redhat.com>
> > > ---
> > > v3: Change the right parameter.
> > > v2: Add "unmap" to block-commit as well. [Kevin]
> > > ---
> > > block/mirror.c | 2 +-
> > > 1 file changed, 1 insertion(+), 1 deletion(-)
> > >
> > > diff --git a/block/mirror.c b/block/mirror.c
> > > index f9d1fec..8847ec5 100644
> > > --- a/block/mirror.c
> > > +++ b/block/mirror.c
> > > @@ -1042,7 +1042,7 @@ void commit_active_start(const char *job_id, BlockDriverState *bs,
> > >
> > > mirror_start_job(job_id, bs, base, NULL, speed, 0, 0,
> > > MIRROR_LEAVE_BACKING_CHAIN,
> > > - on_error, on_error, false, cb, opaque, &local_err,
> > > + on_error, on_error, true, cb, opaque, &local_err,
> > > &commit_active_job_driver, false, base, auto_complete);
> > > if (local_err) {
> > > error_propagate(errp, local_err);
> >
> > Why is unmap an option at all?
> >
> > What's wrong with using BDRV_REQ_MAY_UNMAP on all
> > blk_aio_pwrite_zeroes() calls?
>
> Because unmap is an QMP option of drive-backup. I think in the drive-mirror
> context, it mitigates the limitation that we have no control over target's
> BDRV_O_UNMAP (always inherited from source).
That doesn't explain why unmap is an option.
Is it because the user might not want to unmap the target and would
rather writes zeroes?
For example in qcow2 they might want to leave the data clusters
allocated and simply mark their contents zeroed:
"Standard Cluster Descriptor:
Bit 0: If set to 1, the cluster reads as all zeros. The host
cluster offset can be used to describe a preallocation,
but it won't be used for reading data from this cluster,
nor is data read from the backing file if the cluster is
unallocated."
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 455 bytes --]
next prev parent reply other threads:[~2016-09-30 14:00 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-09-27 11:14 [Qemu-devel] [PATCH v3] block: Turn on "unmap" in active commit Fam Zheng
2016-09-27 13:29 ` Eric Blake
2016-09-27 13:31 ` Eric Blake
2016-09-29 12:41 ` [Qemu-devel] [Qemu-block] " Stefan Hajnoczi
2016-09-30 2:12 ` Fam Zheng
2016-09-30 14:00 ` Stefan Hajnoczi [this message]
2016-09-30 14:19 ` Kevin Wolf
2016-10-28 17:42 ` [Qemu-devel] " Jeff Cody
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=20160930140020.GK24982@stefanha-x1.localdomain \
--to=stefanha@gmail.com \
--cc=famz@redhat.com \
--cc=kwolf@redhat.com \
--cc=mreitz@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).