CEPH filesystem development
 help / color / mirror / Atom feed
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
> 


  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