All of lore.kernel.org
 help / color / mirror / Atom feed
From: Kevin Wolf <kwolf@redhat.com>
To: Eric Blake <eblake@redhat.com>
Cc: qemu-devel@nongnu.org, qemu-block@nongnu.org,
	Max Reitz <mreitz@redhat.com>
Subject: Re: [PATCH 1/4] block: Add bdrv_make_empty()
Date: Tue, 28 Apr 2020 16:16:41 +0200	[thread overview]
Message-ID: <20200428141641.GH5789@linux.fritz.box> (raw)
In-Reply-To: <f9b2b26a-eacd-93db-f5c1-2682ae597e24@redhat.com>

Am 28.04.2020 um 16:07 hat Eric Blake geschrieben:
> On 4/28/20 9:01 AM, Kevin Wolf wrote:
> 
> > > Can we please fix this to take a flags parameter?  I want to make it easier
> > > for callers to request BDRV_REQ_NO_FALLBACK for distinguishing between
> > > callers where the image must be made empty (read as all zeroes) regardless
> > > of time spent, vs. made empty quickly (including if it is already all zero)
> > > but where the caller is prepared for the operation to fail and will write
> > > zeroes itself if fast bulk zeroing was not possible.
> > 
> > bdrv_make_empty() is not for making an image read as all zeroes, but to
> > make it fully unallocated so that the backing file becomes visible.
> > 
> > Are you confusing it with bdrv_make_zero(), which is just a wrapper
> > around bdrv_pwrite_zeroes() and does take flags?
> 
> Yes.  Although now I'm wondering if the two should remain separate or should
> just be a single driver callback where flags can include BDRV_REQ_ZERO_WRITE
> to distinguish whether exposing the backing file vs. reading as all zeroes
> is intended, or if that is merging too much.

I don't think the implementations for both things are too similar, so
you might just end up having two if branches and then two separate
implementations in the block drivers.

If anything, bdrv_make_empty() is more related to discard than
write_zeroes. But we use the discard code for it in qcow2 only as a
fallback because in the most common cases, making an image completely
empty means effectively just creating an entirely new L1 and refcount
table, which is much faster than individually discarding all clusters.

For bdrv_make_zero() I don't see an opportunity for such optimisations,
so I don't really see a reason to have a separate callback. Unless you
do know one?

Kevin



  reply	other threads:[~2020-04-28 14:21 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-04-28 13:26 [PATCH 0/4] block: Do not call BlockDriver.bdrv_make_empty() directly Max Reitz
2020-04-28 13:26 ` [PATCH 1/4] block: Add bdrv_make_empty() Max Reitz
2020-04-28 13:53   ` Eric Blake
2020-04-28 14:01     ` Kevin Wolf
2020-04-28 14:07       ` Eric Blake
2020-04-28 14:16         ` Kevin Wolf [this message]
2020-04-28 14:25           ` Eric Blake
2020-04-28 14:21   ` Kevin Wolf
2020-04-29  7:39     ` Max Reitz
2020-04-28 13:26 ` [PATCH 2/4] block: Use bdrv_make_empty() where possible Max Reitz
2020-04-28 13:54   ` Eric Blake
2020-04-28 15:03   ` Kevin Wolf
2020-04-28 13:26 ` [PATCH 3/4] block: Add blk_make_empty() Max Reitz
2020-04-28 13:55   ` Eric Blake
2020-04-28 14:28     ` Eric Blake
2020-04-28 14:47   ` Kevin Wolf
2020-04-29  7:39     ` Max Reitz
2020-04-28 13:26 ` [PATCH 4/4] block: Use blk_make_empty() after commits Max Reitz
2020-04-28 14:07   ` Eric Blake
2020-04-29  7:58     ` Max Reitz
2020-04-28 15:03   ` Kevin Wolf
2020-04-29  8:01     ` Max Reitz
2020-04-28 13:38 ` [PATCH 0/4] block: Do not call BlockDriver.bdrv_make_empty() directly no-reply
2020-04-28 13:43 ` no-reply
2020-04-28 13:57   ` Eric Blake
2020-04-28 13:48 ` no-reply
2020-04-28 13:49 ` Eric Blake
2020-04-28 14:05   ` Eric Blake
2020-04-28 14:53 ` no-reply
2020-04-28 14:57 ` no-reply
2020-04-28 15:02 ` no-reply

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=20200428141641.GH5789@linux.fritz.box \
    --to=kwolf@redhat.com \
    --cc=eblake@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 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.