All of lore.kernel.org
 help / color / mirror / Atom feed
From: Josh Durgin <josh.durgin@inktank.com>
To: Alex Elder <elder@inktank.com>
Cc: ceph-devel@vger.kernel.org
Subject: Re: [PATCH 0/4] rbd: get rid of the snapshot list
Date: Tue, 30 Apr 2013 17:57:51 -0700	[thread overview]
Message-ID: <5180688F.1020703@inktank.com> (raw)
In-Reply-To: <517FBBF0.9020904@inktank.com>

On 04/30/2013 05:41 AM, Alex Elder wrote:
> An rbd device structure maintains a list of snapshot
> structures whose purpose is to cache the name, size,
> and features associated with a snapshot id.  The main
> reason it was needed was related to the presence of
> Linux device information for snapshots, which we
> no longer have.  We can look up the name, etc. "on
> the fly" about as easily as we can using the list,
> and getting rid of this list means we can eliminate
> a substantial bit of code.
>
> The final patch in this series gets rid of the snapshot
> list and the rbd_snap structure.  The first three put
> in place replacement functionality that doesn't require
> the list.
>
> 					-Alex
>
> [PATCH 1/4] rbd: look up snapshot name in names buffer
> [PATCH 2/4] rbd: use snap_id not index to look up snap info
> [PATCH 3/4] rbd: define rbd_snap_size() and rbd_snap_features()
> [PATCH 4/4] rbd: kill off the snapshot list

These patches look good, but bring up two things that should be 
addressed in later patches.

1) inefficient snapshot id lookup for format 2 images

We're sending a single request for each snapshot id in the snapshot
context. There could potentially be a very large number of snapshots
there, hundreds or even thousands, which would slow down mapping
a snapshot quite a bit. Aggregating this into a request with multiple
ops so we get, perhaps, up to 500 snapshot names at a time would
make this a lot faster.

2) mapped snapshots never clear the EXISTS flag

Now that we're not keeping a snapshot list, we don't check whether
the snapshot we mapped continues to exist. Since we know the snapshot
id, we just need to see if it's still present in the updated snapshot
context.

These aren't critical though, so this patch series looks good as is:
Reviewed-by: Josh Durgin <josh.durgin@inktank.com>

  parent reply	other threads:[~2013-05-01  0:58 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-04-30 12:41 [PATCH 0/4] rbd: get rid of the snapshot list Alex Elder
2013-04-30 12:42 ` [PATCH 1/4] rbd: look up snapshot name in names buffer Alex Elder
2013-04-30 12:42 ` [PATCH 2/4] rbd: use snap_id not index to look up snap info Alex Elder
2013-04-30 12:42 ` [PATCH 3/4] rbd: define rbd_snap_size() and rbd_snap_features() Alex Elder
2013-04-30 12:43 ` [PATCH 4/4] rbd: kill off the snapshot list Alex Elder
2013-05-01  0:57 ` Josh Durgin [this message]
2013-05-01  1:12   ` [PATCH 0/4] rbd: get rid of " Alex Elder
2013-05-01  1:16     ` Alex Elder
2013-05-01  1:32     ` Josh Durgin

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=5180688F.1020703@inktank.com \
    --to=josh.durgin@inktank.com \
    --cc=ceph-devel@vger.kernel.org \
    --cc=elder@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.