From: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
To: Eric Blake <eblake@redhat.com>, qemu-devel@nongnu.org
Cc: kwolf@redhat.com, qemu-block@nongnu.org, stefanha@redhat.com,
rjones@redhat.com, John Snow <jsnow@redhat.com>,
Max Reitz <mreitz@redhat.com>, Fam Zheng <fam@euphon.net>
Subject: Re: [PATCH v5 10/12] block: Return depth level during bdrv_is_allocated_above
Date: Sat, 24 Oct 2020 12:49:49 +0300 [thread overview]
Message-ID: <caeff8a0-a4b6-0835-27c9-726cc8f94304@virtuozzo.com> (raw)
In-Reply-To: <20201023183652.478921-11-eblake@redhat.com>
23.10.2020 21:36, Eric Blake wrote:
> When checking for allocation across a chain, it's already easy to
> count the depth within the chain at which the allocation is found.
> Instead of throwing that information away, return it to the caller.
> Existing callers only cared about allocated/non-allocated, but having
> a depth available will be used by NBD in the next patch.
>
> Note that the previous code (since commit 188a7bbf94 in 2012) was
> lazy: for each layer deeper in the backing chain, it was issuing a
> bdrv_is_allocated request on the original 'bytes' amount, rather than
> on any smaller amount 'n' learned from an upper layer. These
> semantics happened to work, since if you have:
>
> Base <- Active
> XX-- -XX-
>
> the consecutive results are offset 0: '11' with *pnum 2, followed by
> offset 2: '1' with *pnum 1, followed by offset 3: '0' with *pnum 1;
> the resulting sequence 1110 matches reality (the first three clusters
> are indeed allocated somewhere in the given range). But post-patch,
> we correctly give the results offset 0: '2' with *pnum 1, followed by
> offset 1: '11' with *pnum 2, followed by offset 3: '0' with *pnum 1
> (2110), without over-reporting the length of contributions from the
> backing layers.
>
> Signed-off-by: Eric Blake <eblake@redhat.com>
This conflicts with block-status/is-allocated fix/merge patches in Stefan's "[PULL v3 00/28] Block patches"
--
Best regards,
Vladimir
next prev parent reply other threads:[~2020-10-24 9:52 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-10-23 18:36 [PATCH v5 00/12] Exposing backing-chain allocation over NBD Eric Blake
2020-10-23 18:36 ` [PATCH v5 01/12] qapi: Move GenericList to qapi/util.h Eric Blake
2020-10-24 9:06 ` Vladimir Sementsov-Ogievskiy
2020-10-26 14:18 ` Markus Armbruster
2020-10-26 14:22 ` Eric Blake
2020-10-23 18:36 ` [PATCH v5 02/12] qapi: Make QAPI_LIST_ADD() public Eric Blake
2020-10-24 9:10 ` Vladimir Sementsov-Ogievskiy
2020-10-26 14:25 ` Markus Armbruster
2020-10-26 14:37 ` Eric Blake
2020-10-26 14:38 ` Eric Blake
2020-10-23 18:36 ` [PATCH v5 03/12] nbd: Utilize QAPI_CLONE for type conversion Eric Blake
2020-10-24 9:17 ` Vladimir Sementsov-Ogievskiy
2020-10-26 14:41 ` Markus Armbruster
2020-10-23 18:36 ` [PATCH v5 04/12] nbd: Add new qemu:allocation-depth metadata context Eric Blake
2020-10-23 18:36 ` [PATCH v5 05/12] nbd: Add 'qemu-nbd -A' to expose allocation depth Eric Blake
2020-10-23 18:36 ` [PATCH v5 06/12] nbd: Update qapi to support exporting multiple bitmaps Eric Blake
2020-10-26 10:50 ` Peter Krempa
2020-10-26 13:06 ` Eric Blake
2020-10-23 18:36 ` [PATCH v5 07/12] nbd: Simplify qemu bitmap context name Eric Blake
2020-10-23 18:36 ` [PATCH v5 08/12] nbd: Refactor counting of metadata contexts Eric Blake
2020-10-23 18:36 ` [PATCH v5 09/12] nbd: Allow export of multiple bitmaps for one device Eric Blake
2020-10-23 18:36 ` [PATCH v5 10/12] block: Return depth level during bdrv_is_allocated_above Eric Blake
2020-10-24 9:49 ` Vladimir Sementsov-Ogievskiy [this message]
2020-10-26 12:26 ` Vladimir Sementsov-Ogievskiy
2020-10-23 18:36 ` [PATCH v5 11/12] nbd: Expose actual depth in qemu:allocation-depth Eric Blake
2020-10-24 9:59 ` Vladimir Sementsov-Ogievskiy
2020-10-26 12:31 ` Eric Blake
2020-10-23 18:36 ` [PATCH v5 12/12] qapi: Use QAPI_LIST_ADD() where possible Eric Blake
2020-10-23 20:23 ` Eric Blake
2020-10-23 18:44 ` [PATCH v5 00/12] Exposing backing-chain allocation over NBD Eric Blake
2020-10-26 14:54 ` Markus Armbruster
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=caeff8a0-a4b6-0835-27c9-726cc8f94304@virtuozzo.com \
--to=vsementsov@virtuozzo.com \
--cc=eblake@redhat.com \
--cc=fam@euphon.net \
--cc=jsnow@redhat.com \
--cc=kwolf@redhat.com \
--cc=mreitz@redhat.com \
--cc=qemu-block@nongnu.org \
--cc=qemu-devel@nongnu.org \
--cc=rjones@redhat.com \
--cc=stefanha@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 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).