[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH v5 10/12] block: Return depth level during bdrv_is_allocated_

From: Vladimir Sementsov-Ogievskiy
Subject: Re: [PATCH v5 10/12] block: Return depth level during bdrv_is_allocated_above
Date: Mon, 26 Oct 2020 15:26:54 +0300
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.4.0

24.10.2020 12:49, Vladimir Sementsov-Ogievskiy wrote:
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"

the patches applied to master branch

Best regards,

reply via email to

[Prev in Thread] Current Thread [Next in Thread]