All of lore.kernel.org
 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 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.