On Fri, May 25, 2012 at 4:07 PM, Josh Durgin <josh.durgin@xxxxxxxxxxx> wrote: > 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? One thing: that's still racy, and we discussed a solution. 1. A: walk through all pools, look for clones, find none 2. B: create a clone 3. A: rbd unpreserve parent 4. A: rbd rm parent Oopsie. To avoid that, I proposed a "deleting" flag. Clones can only be created when parent is preserved && !deleting. Now, 1. A: rbd deleting parent 2. A: walk through all pools, look for clones, find none 3. B: attempt to create a clone, fails ... Now, that doesn't have to be strictly "deleting".. "going_unpreserved" or something; instead of deletion, the intended operation might be starting a vm against the parent image to e.g. add security updates. And, as we discussed, these flags would be per snapshot (or also on the master image, if you want to support that). Thus, one snapshot can preserved while an older one is scheduled for deletion. -- To unsubscribe from this list: send the line "unsubscribe ceph-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
