On 06/18/2012 10:00 AM, Tommi Virtanen wrote:
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
Agreed.
$ rbd list_children pool/image@snap
pool2/child1
pool2/child2
How about just "rbd children"? Especially the underscore makes me unhappy.
Yeah, that sounds better.
$ 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"?
I'm not sure what best term is, but there's probably something better
than copyup.
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.
The reason for making it a class method is more about hiding the
implementation from clients. It could be the mapping you describe in
an omap.
--
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
