[Sheepdog] Drive snapshots and metadata

[MORITA Kazutaka]

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