At Thu, 7 Oct 2010 08:53:41 +0200,
Floris Bos wrote:
>
> 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.
>
Yes, probably. Pseude-code of the background daemon to reclaim
objects would be the following (not implemented yet):
foreach vdi in sheepdog.vdis
foreach obj in vdi.data_objs
ref_cnt := 0
foreach neighbor_vdi in vdi.neighbors
if neighbor_vdi.data_objs.contains(obj) then
ref_cnt := ref_cnt + 1
end if
end foreach
if ref_cnt = 0 then
delete obj
end if
end foreach
end foreach
Here sheepdog.vdis is all the vdis (snapshots are also included), and
vdi.neighbors is a set of the vdis which contains its parent snapshot
and its children snapshots. I think moving the current vid_id doesn't
hurt the algorithm.
Currently, sheepdog deletes objects only when all the snapshot and
current vdis of the target name are deleted. In this case, we can
delete all the data objects of the vdis because no vdi doesn't use the
objects. See also the commit log of
http://sheepdog.git.sf.net/git/gitweb.cgi?p=sheepdog/sheepdog;h=e88252368e43db3011b6279a65d8cf3df8bf67c0
Thanks,
Kazutaka
|
|