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 > > > 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. Thanks, Kazutaka |