[Sheepdog] Deleting snapshots

[Floris Bos]

Hi,

On Thursday, October 07, 2010 08:00:02 am you wrote:
> At Thu, 7 Oct 2010 06:28:55 +0200,
> > Ideally there should be a way to signal the client to only use COW
> > temporarily (while any snapshot exist), and signal it again that it can
> > resume updating in-place after there are no longer any snapshots.
> 
> I think this kind of feature would be useful in practice.  If a sheep
> daemon could tell the virtual machine to use the previous vdi id, we
> could achieve this feature easily, I think.  In this case, write
> accesses to the objects which were already updated during rsync are
> done in copy-on-write way again, and other accesses are done in-place.

Sounds like a good plan.


Does changing the vid_id back and forth again one also plays nice with the 
algorithm you use (or plan to use?) for deleting objects that are no longer in 
use?
Not sure if I understand how that exactly works.


> > Asynchronous notification might be relatively complicated to implement in
> > the qemu block driver, though.
> > Wonder if it might be more practical to transfer some of the low level
> > stuff that is currently in the qemu client itself, to sheep.
> > And let sheep offer a simplified protocol to the client, that does not
> > think in low level details like which object the data should be written
> > to, but just specifies "offset" and "data length" to write to in the
> > image.
> > So that sheep can decide whether or not cow should be used, and also
> > manage other low level details (like updating inode metadata) instead of
> > the client.
> 
> Yes, that might be more practical, but makes a sheep daemon more
> complicated.  Current sheepdog implementation provides something like
> a simple object storage to the qemu block driver, but I think that
> managing which object should be updated in COW way is out of scope of
> the object storage.

Ok.
I see your point.
 
> I guess the notification feature is not so complicated.  What the qemu
> block driver has to do is only updating its vdi object when the driver
> receives SD_RES_READONLY in the response of write operation,

You're right. Could be used for both notifications.


-- 
Yours sincerely,

Floris Bos