At Fri, 4 Feb 2011 19:51:11 +0000, Chris Webb wrote: > > MORITA Kazutaka <morita.kazutaka at lab.ntt.co.jp> writes: > > > Chris Webb wrote: > > > I can create a snapshot of the source with qemu-img snapshot, and then > > > do > > > > > > qemu-img create -b sheepdog:source:1 sheepdog:dest > > > > > > However, I think that I can't then delete the snapshot source:1 and the > > > original source drive without also deleting the dest drive? Am I right > > > about this, or am I misunderstanding or out-of-date with the current > > > state of sheepdog? > > > > You are right. Although we can delete the snapshot source:1 with "collie > > vdi delete src -s 1", the data objects of the snapshot aren't reclaimed > > until the dest image is deleted. This should be fixed, but it is a bit > > difficult to implement it. > > The situation here's better than I realised, though: from what you say we can > delete both source and source:1, and although the blocks from source:1 > aren't freed, they get automatically freed when dest is deleted? More > generally, if I've used this procedure to clone a -> b -> c, and delete a > and b, both won't get freed until c does, but there's no leak provided all > three eventually get deleted? Yes, exactly. > > > It sounds good to me to have the feature in Sheepdog. Storing > > something like accounting information is necessary feature for hosting > > use. How about the following commands? > > > > $ collie vdi setdata [key] [value] > > $ collie vdi getdata [key] > > That would be perfect for management purposes, yes! Maybe also > > $ collie vdi setdata [key] > > to unset the key, so getdata returns an error code? Yes, it is necessary too. On second thought, "setattr/getattr" looks better to me because it is like an extended attribute of a file. And if so, it may be better that "setattr" reads a value from stdin like the attr command by default; $ collie vdi setattr [key] < value_file or $ collie vdi setattr [key] -V [value] In that case, to unset key, a delete option would be required. $ collie vdi setattr [key] -d > > In an ideal world, it would be good to have some sort of > no-clobber/exclusive mechanism too. For example: > > $ collie vdi setdata [key] [value] exclusive > > which if [key] is unset, sets it to value [value], or if it is set, fails > with non-zero exit code. (This could be used by a management layer to > implement exclusive access to drives, for example.) Yes, it would be useful to have the feature. I think we can simply implement the aboves if we don't support listing attributes like $ collie vdi listattrs [key] This may be useful, but I'll leave it for now. Thanks, Kazutaka |