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? > 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? 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.) Best wishes, Chris. |