On 05/25/2012 01:55 PM, Greg Farnum wrote:
On Thursday, May 24, 2012 at 4:05 PM, Josh Durgin wrote:
<snip>
One thing that's not addressed in the earlier design is how to make
images read-only. The simplest way would be to only support layering
on top of snapshots, which are read-only by definition.
Another way would be to allow images to be set read-only or
read-write, and disallow setting images with children read-write. Are
there many use cases that would justify this second, more complicated
way?
I'm pretty sure we want to require images to be based on snapshots. It's
actually more flexible than read-write flags: service providers could provide
several Ubuntu 12.04 installs with different packages available by simply
snapshotting as they go through the install procedure. If they instead had to
go to an endpoint and then mark the image read-only, they would need to
duplicate all the shared data.
I like this approach better myself, since it's less confusing and has
a smaller potential for errors.
Copy-up
=======
Another feature we want to include with layering is the ability to
copy all remaining data from the parent image to the child image, to
break the dependency of the latter on the former. This does not change
snapshots that were taken earlier though - they still rely on the
parent image. Thus, the children of a parent image will need to
include snapshots as well, and the reference to the parent image will
be needed to interact with snapshots. Thus, we can't just remove the
information pointing the parent. Instead, we can add a boolean
has_parent field that is stored in the header and with each snapshot,
since some snapshots may be taken when the parent was still used, and
some after all the data has been copied to the child.
I understand why you're maintaining a reference to the parent image for old
snapshots, but it makes me a little uneasy. This limitation means that you
either need to delete snapshots or you need to maintain access to the parent
image, which makes me a sad panda.
Have you looked into options for doing a full "local" copy of the needed parent
data? I realize there are several tricky problems, but given some of the usage scenarios
for layering (ie, migration) it would be an advantage.
I'm not quite sure what you mean by a full "local" copy.
My plan was to treat snapshots as extra children of the parent if they
reference it. That is, snapshotting a cloned image would include
calling add_child on the parent. This ensures that the parent won't be
deleted if child images or snapshots still need it.
My last question is about recursive layering. I know it's been discussed some,
and *hopefully* it won't impact the actual on-disk layout of RBD images; do you
have enough of a design sketched out to be sure? (One example: given the
security concerns you've raised, I think layered images are going to need to
list themselves as a child of each of their ancestors, rather than letting that
information be absorbed by the intermediate image. Can the plan for storing
parent pointers handle that?)
Since parents maintain a list of children, there's no need to add
references at more than one level. If you have images A, B, and C,
with each a child of the last, A can't be deleted until B is, and B
can't be deleted until C is.
The only restriction is that the client needs to have read access to
all the parent pools.
--
To unsubscribe from this list: send the line "unsubscribe ceph-devel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
