From: Alex Elder <elder@ieee.org>
To: Ilya Dryomov <ilya.dryomov@inktank.com>
Cc: Ceph Development <ceph-devel@vger.kernel.org>
Subject: Re: [PATCH 6/8] rbd: update mapping size only on refresh
Date: Thu, 24 Jul 2014 12:59:34 -0500 [thread overview]
Message-ID: <53D14986.70004@ieee.org> (raw)
In-Reply-To: <CALFYKtAGMmBvb-ujedZK_rctH5XDMGwVR262jVwbev9GQsbD8A@mail.gmail.com>
On 07/24/2014 08:46 AM, Ilya Dryomov wrote:
> On Thu, Jul 24, 2014 at 5:25 PM, Alex Elder <elder@ieee.org> wrote:
>> On 07/24/2014 03:42 AM, Ilya Dryomov wrote:
>>> There is no sense in trying to update the mapping size before it's even
>>> been set.
>>
>> It took me a bit to follow this. But basically there is
>> no mapping unless it's mapped. So previously this was
>> updating the mapping information even for unmapped
>> parent (or other) images. There's no need to update
>> the mapping size for a snapshot--it'll never change.
>>
>> Is that right? If not, please advise; otherwise:
>
> No. Previously it was updating the mapping size both on the inital map
> and on refresh (of the base image). Doing that on the inital map
> doesn't make sense: not only struct rbd_mapping fields aren't properly
> initialized at that point - rbd_dev_mapping_set() is called much later
> in the map sequence, snap_id isn't initialized either (at least in the
> format 2 case, I haven't looked too closely at the format 1 case). And
> just in general, trying to update something before it had a chance to
> change is bogus..
OK, now I see it. Hopefully this makes sense. Here is how it
was previously structured:
rbd_add()
do_rbd_add()
|rbd_dev_image_probe()
| rbd_dev_header_info()
| rbd_dev_v1_header_info() or rbd_dev_v2_header_info()
| rbd_header_from_disk() <update mapping>
| <update mapping>
| . . .
|rbd_dev_device_setup()
| rbd_dev_mapping_set()
So neither rbd_header_from_disk() nor rbd_dev_v2_header_info()
should be using the values in the rbd_dev->mapping field during
initial image probe, because they have not yet been initialized
at that point.
Meanwhile, the only reason we need to *update* a mapping size
is if we learn it may have changed, which will be covered by a
refresh, so doing so in rbd_dev_refresh() makes sense. And
as long as you know whether it's mapping the base image you
might as well do the rbd_exists_validate() call conditionally.
OK, this all looks good and makes good sense to me.
Thank you for explaining it.
Reviewed-by: Alex Elder <elder@linaro.org>
>
> Thanks,
>
> Ilya
>
next prev parent reply other threads:[~2014-07-24 17:59 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-07-24 8:42 [PATCH 0/8] wip-overlap Ilya Dryomov
2014-07-24 8:42 ` [PATCH 1/8] rbd: show the entire chain of parent images Ilya Dryomov
2014-07-24 12:31 ` Alex Elder
2014-07-24 12:45 ` Ilya Dryomov
2014-07-24 8:42 ` [PATCH 2/8] rbd: introduce rbd_dev_header_info() Ilya Dryomov
2014-07-24 12:34 ` Alex Elder
2014-07-24 8:42 ` [PATCH 3/8] rbd: remove unnecessary asserts in rbd_dev_image_probe() Ilya Dryomov
2014-07-24 12:40 ` Alex Elder
2014-07-24 8:42 ` [PATCH 4/8] rbd: split rbd_dev_spec_update() into two functions Ilya Dryomov
2014-07-24 12:55 ` Alex Elder
2014-07-24 8:42 ` [PATCH 5/8] rbd: harden rbd_dev_refresh() caller Ilya Dryomov
2014-07-24 13:09 ` Alex Elder
2014-07-24 8:42 ` [PATCH 6/8] rbd: update mapping size only on refresh Ilya Dryomov
2014-07-24 13:25 ` Alex Elder
2014-07-24 13:46 ` Ilya Dryomov
2014-07-24 15:10 ` Ilya Dryomov
2014-07-25 13:31 ` Alex Elder
2014-07-24 17:59 ` Alex Elder [this message]
2014-07-24 8:42 ` [PATCH 7/8] rbd: do not read in parent info before snap context Ilya Dryomov
2014-07-25 8:14 ` Alex Elder
2014-07-25 8:36 ` Ilya Dryomov
2014-07-25 12:46 ` Alex Elder
2014-07-24 8:42 ` [PATCH 8/8] rbd: take snap_id into account when reading in parent info Ilya Dryomov
2014-07-24 18:43 ` Alex Elder
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=53D14986.70004@ieee.org \
--to=elder@ieee.org \
--cc=ceph-devel@vger.kernel.org \
--cc=ilya.dryomov@inktank.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