Re: RBD format changes and layering

[Josh Durgin <josh.durgin@inktank.com>]

On 05/24/2012 04:05 PM, Josh Durgin wrote:
> 1) making sure parent images are not deleted when children still
> refer to them

Yehuda and Tv and I talked about this more, and came up with a simpler
design that doesn't require the security changes or writing anything
to the parent.

Each image (and snapshot) has a 'preserved' flag that means it is 
read-only and cannot be deleted without explicitly declaring it
deletable. Something like:

   $ rbd preserve pool/image
   $ rbd rm pool/image
   Error: image is preserved. If you really know what you're doing, 
unpreserve it.
   $ rbd unpreserve pool/image
   $ rbd rm pool/image

Images or snapshots that don't have the preserved flag set can't be
cloned. Images or snapshots that do have it set can't be deleted until
it is unset.

To answer the question 'does this image have children', we can have an
object in the child's pool that maintains info about which children
exist in that pool (rbd_clones). This could be an omap with keys of
(parent pool id, parent image id, parent snap name, child image id,
child snap name) and empty values, or keys with the parent info and
values consisting of lists of child info.

To check whether children exist, you can iterate over
all the pools and check the rbd_clones object in each one.
Since the number of pools is relatively small, this isn't
very expensive. If the pool is deleted, by definition all the children 
in it are deleted.

With separate namespaces in the future, this will be a bit more
expensive, but it's only needed at base image deletion time,
which is relatively rare. Deleting the image itself already
requires an I/O per object, so this is probably not the slow
part anyway.

Yehuda, Tv, did I miss anything?

Josh