All of lore.kernel.org
 help / color / mirror / Atom feed
From: Josh Durgin <josh.durgin@dreamhost.com>
To: Tommi Virtanen <tommi.virtanen@dreamhost.com>
Cc: ceph-devel <ceph-devel@vger.kernel.org>
Subject: Re: RBD layering needs to work across pools
Date: Fri, 16 Dec 2011 16:26:21 -0800	[thread overview]
Message-ID: <4EEBE1AD.5090507@dreamhost.com> (raw)
In-Reply-To: <CAORUGqAudf68yWzQhgFND1Dh1sxM2ArUitbn_s16acsS2W29wQ@mail.gmail.com>

On 12/16/2011 03:40 PM, Tommi Virtanen wrote:
> On Fri, Dec 16, 2011 at 14:48, Tommi Virtanen
> <tommi.virtanen@dreamhost.com>  wrote:
>> To support this, we'd need to make sure the RBD layering we're
>> building is able to use base images in a separate pool. (And handle
>> the ugly case where after a misconfiguration the client can't access
>> the base image anymore...)
>>
>> Josh, can you say whether that falls in line with what's been planned
>> for the layering?
>
> Nevermind, I see parent_{pool, image_id, snap_id} in
> http://tracker.newdream.net/issues/1772
>
> Just keep that in mind as a hard requirement.

Also note that the plan includes setting a read-only flag on
images that have clones, so there's no danger of a parent image
being modified underneath a child image.

There is one detail that we didn't realize while planning this
though - our current plan calls for the parent image to keep
track of a list of child images, which needs to be updated
whenever a child image is created or deleted.

We were planning on storing this in the parent's header, which
would be in the parent's pool. This means that cloning an image
or deleting a cloned image would require write access to the
parent's pool. We might need to rethink this a little.

      parent reply	other threads:[~2011-12-17  0:26 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-12-16 22:48 RBD layering needs to work across pools Tommi Virtanen
2011-12-16 23:40 ` Tommi Virtanen
2011-12-16 23:45   ` Gregory Farnum
2011-12-17  0:26   ` Josh Durgin [this message]

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=4EEBE1AD.5090507@dreamhost.com \
    --to=josh.durgin@dreamhost.com \
    --cc=ceph-devel@vger.kernel.org \
    --cc=tommi.virtanen@dreamhost.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.