[Sheepdog] [PATCH v3] sheep: change snapshot/clone flow

[HaiTing Yao]

On Thu, Apr 26, 2012 at 1:16 AM, MORITA Kazutaka <
morita.kazutaka at lab.ntt.co.jp> wrote:

> At Tue, 24 Apr 2012 14:24:04 +0800,
>  HaiTing Yao wrote:
> >
> > I used collie tool to test and get this result.
> >
> > Before my modification, the relation as belowe
> >
> > [wujue.yht at v134092.sqa.cm4 ~]$ collie vdi list
> >   Name        Id    Size    Used  Shared    Creation time   VDI id  Tag
> > s v1           1  1.0 GB   20 MB  0.0 MB 2012-04-24 11:23   709128
> > s v1           2  1.0 GB  0.0 MB   20 MB 2012-04-24 11:24   709129
> >   v1           3  1.0 GB  0.0 MB   20 MB 2012-04-24 11:24   70912a
> >
> > vdi ID 709128
> > its parent ID 0
> > its 1st child id 709129
> >
> > vdi ID 709129
> > its parent ID 709128
> > its 1st child id 70912a
> >
> > vdi ID 70912a
> > its parent ID 709129
> > no child
> >
> > After my modification, the relation as belowe. All of snapshots belong to
> > base VDI. Would you mind give the details you expected, thanks.
> >
> > [wujue.yht at v134092.sqa.cm4 ~]$ collie vdi list
> >   Name        Id    Size    Used  Shared    Creation time   VDI id  Tag
> >  v1           1  1.0 GB   20 MB  0.0 MB 2012-04-24 11:23   709128
> > s v1           2  1.0 GB  0.0 MB   20 MB 2012-04-24 11:24   709129
> > s v1           3  1.0 GB  0.0 MB   20 MB 2012-04-24 11:24   70912a
> >
> > vdi ID 709128
> > its parent ID 0
> > its 1st child id 709129
> > its 2nd child id 70912a
>
> 709128 is the current branch, so
>  - it shouldn't have children.
>  - its parent should be 70912a since it is the previous current vdi.
>
> >
> > vdi ID 709129
> > its parent ID 709128
> > no child
>
> 709129 is the first snapshot of this vdi, so
>  - it shouldn't have a parent
>  - its children should be 70912a since it is the next snapshot
>
> >
> > vdi ID 70912a
> > its parent ID 709128
> > no child
>
>  - its parent should be 709129
>  - its child should be 709128
>
>
> What we want to do is to show snapshots relationships as VMware does.
>
>  http://www.vmware.com/support/ws55/doc/ws_preserve_sshot_manager.html
>

If we need these one-by-one parent/child relation and do not change inode
structure, let's keep the codes now and abandon my patch.

As you say we can display the current Id as zero and removing VDI id
from the output of 'collie vdi list'. The VDI id may be the reason why we
confused. I will submit one patch about these.

Thanks
Haiti

>
>
> > > > BTW, since we change the inode structure, how about increse the
> > > > SD_PROTO_VER?
> > >
> > > If we would merge this change, we must increment SD_PROTO_VER.  But
> > > I'm still not sure this change is really necessary.  As I said before,
> > > I'd like to avoid changing the sheepdog_inode structure if possible.
> > > If we don't show VDI id in the output of 'collie vdi list', there is
> > > no confusing issue you want to fix, no?
> > >
> > > Thanks,
> > >
> > > Kazutaka
> > >
> >
> > Besides confusing, there is some other conditions we need to consider.
> >
> > 1, find_first_vdi() looks up from the right side of the hash point. The
> new
> > created VDI bacomes the base VDI, so we must begin looking up from right
> > side. We find the next zero from the hash point at bitmap, and use the
> next
> > zero as the right side edge. Then we can not clear bitmap anytime,
> because
> > we need the next zero as the right side point. The 1 at bitmap does not
> > mean the VDI ID is used, we must check the inode object and find its name
> > is null or not. Without the patch, we must do like this and did like
> > this. With the patch, base VDI is never changed so we can look up from
> the
> > left side.
> >
> > 2, Before the patch, every VDI have one child at most in inode. It is
> > hard to control children maximum, and can not delete any inode object of
> > snapshots. If we miss one, the tree list is broken because parent/child
> > relation is one by one.
> >
> > I do not thik this patch is good enough for these problems, and perhaps
> we
> > have better soultions.
>
> I see the problem, but I'd like to see another approach instead of
> changing the current vdi relationships.
>

If we start looking up from the right side for the base VDI, we can not
delete VDI gracefully. I thinked about it.  Since the parent of first VDI
is zero now, how about assign the latest VDI id to it?

 Then it seems like double-linked list. When do 'collie vdi graph', we can
change the parent VDI ID to zero trickily.

Thanks
Haiti

>
> Thanks,
>
> Kazutaka
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.wpkg.org/pipermail/sheepdog/attachments/20120427/06d61eee/attachment-0003.html>