On Fri, Jun 15, 2012 at 1:48 PM, Josh Durgin <josh.durgin@xxxxxxxxxxx> wrote: > $ rbd unpreserve pool/image@snap > Error unpreserving: child images rely on this image UX nit: this should also say what image it found. rbd: Cannot unpreserve: Still in use by pool2/image2 > $ rbd list_children pool/image@snap > pool2/child1 > pool2/child2 How about just "rbd children"? Especially the underscore makes me unhappy. > $ rbd copyup pool2/child1 Does "copyup" make sense to everyone? Every time you say it, my brain needs to flip the image inside the other way around -- I naturally imagine a tree with the parent at the top, and children and grandchildren down from it, but then I can't call that operation "copyup" without wrecking my mental image. I also can't seem to google good evidence that the term would be in widespread use in the enterprisey block storage world, outside of the unionfs world.. What do people call the un-dedupping, un-thinning of copy-on-write thin provisioning? "unshare"? > In addition to knowing which parent a given image has, we want to be > able to tell if a preserved image still has children. This is > accomplished with a new per-pool object, `rbd_children`, which maps > (parent pool, parent id, parent snapshot id) to a list of child > image ids. So the omap value is a list, and you need to support atomic add/remove on the list members? Are you thinking of using an rbd class method that does read-modify-write for that? My instincts would have gone for (parent_pool, parent_id, parent_snapshot_id, child_id) -> None, to get atomic operations for free. -- 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
