[Sheepdog] Drive snapshots and metadata

[Chris Webb]

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.