[Sheepdog] [PATCH v3] sheep: change snapshot/clone flow
HaiTing Yao
yaohaiting.wujue at gmail.com
Tue Apr 24 08:24:04 CEST 2012
On Tue, Apr 24, 2012 at 1:00 AM, MORITA Kazutaka
<morita.kazutaka at gmail.com>wrote:
> At Mon, 23 Apr 2012 11:37:11 +0800,
> HaiTing Yao wrote:
> >
> > On Sat, Apr 21, 2012 at 4:56 AM, MORITA Kazutaka
> > <morita.kazutaka at gmail.com>wrote:
> >
> > > At Fri, 20 Apr 2012 14:40:26 +0800,
> > > yaohaiting.wujue at gmail.com wrote:
> > > >
> > > > From: HaiTing Yao <wujue.yht at taobao.com>
> > > >
> > > > When create snapshot for source VDI, the new created VDI used as
> source
> > > > VDI, and the old source VDI used as snapshot. This flow make users
> > > > confused about VDI and snapshot relation. The snapshot metadata
> maybe is
> > > > stored on multi-VDI, so need read multi VDIs inode to get snapshot
> list.
> > > >
> > > > When create snapshot, we does not need change new created VDI to
> source
> > > > VDI. The source VDI just need use snapshot VDI ID as its object data
> ID.
> > > >
> > > > Show one example.
> > > >
> > > > Before modification:
> > > >
> > > > Name Id Size Used Shared Creation time VDI id
> Tag
> > > > s v1 1 64 MB 20 MB 0.0 MB 2012-03-26 16:55 709128
> > > > s v1 2 64 MB 0.0 MB 20 MB 2012-03-26 16:56 709129
> sn3
> > > > v1 3 64 MB 0.0 MB 20 MB 2012-03-26 16:56 70912a
> > > >
> > > > After modification:
> > > >
> > > > Name Id Size Used Shared Creation time VDI id
> Tag
> > > > v1 0 64 MB 20 MB 0.0 MB 2012-03-27 11:06 709128
> > > > s v1 1 64 MB 0.0 MB 20 MB 2012-03-27 11:06 709129
> > > > s v1 2 64 MB 0.0 MB 20 MB 2012-03-27 11:07 70912a
> sn3
> > > >
> > > > Signed-off-by: HaiTing Yao <wujue.yht at taobao.com>
> > > > ---
> > > > collie/common.c | 2 +-
> > > > collie/vdi.c | 33 ++++++++++++++++++++++-----------
> > > > include/sheepdog_proto.h | 6 ++++--
> > > > sheep/vdi.c | 18 ++++++++++--------
> > > > 4 files changed, 37 insertions(+), 22 deletions(-)
> > >
> > > Your patch breaks the relationship between VDI snapshots.
> > > For example:
> > > ==
> > > $ collie cluster format -c 1
> > >
> > > $ qemu-img create sheepdog:test 4G
> > > $ qemu-img snapshot -c tag1 sheepdog:test
> > > $ qemu-img snapshot -c tag2 sheepdog:test
> > > $ qemu-img snapshot -c tag3 sheepdog:test
> > >
> > > $ qemu-img create sheepdog:test2 4G
> > > $ qemu-img snapshot -c tag1 sheepdog:test2
> > > $ qemu-img snapshot -c tag2 sheepdog:test2
> > > $ qemu-io -c "write 0 512" sheepdog:test2:1
> > > $ qemu-img snapshot -c tag3 sheepdog:test2
> > >
> > > $ collie vdi tree
> > > ==
> > >
> > > and the expected output is:
> > > ==
> > > test---[2012-04-21 05:51]---[2012-04-21 05:51]---[2012-04-21
> > > 05:51]---(you are here)
> > > test2---[2012-04-21 05:51]-+-[2012-04-21 05:51]---[2012-04-21 05:51]
> > > `-[2012-04-21 05:51]---(you are here)
> > > ==
> > >
> >
> > I think you have applied my block/sheepdog.c patch for qemu project.
> There
> > is still something to do. qemu-img is still having some problem with
> object
> > cache when there is snapshot. The work is on the progress by Liuyuan as I
> > knew. Perhaps you can shutdown object cache temporarily by this:
>
> No, the cache is not a problem here.
>
>
> >
> > void do_io_request(struct work *work)
> >
> > dprintf("%x, %" PRIx64" , %u\n", opcode, oid, epoch);
> > + hdr->flags = hdr->flags & ~SD_FLAG_CMD_CACHE;
> > if (hdr->flags & SD_FLAG_CMD_RECOVERY)
> >
> > Then the display like this
> >
> > [wujue.yht at v134092.sqa.cm4 ~]$ clv
> > Name Id Size Used Shared Creation time VDI id Tag
> > v1 0 1.0 GB 0.0 MB 0.0 MB 2012-04-23 10:45 709128
> > img1 0 1.0 GB 0.0 MB 0.0 MB 2012-04-23 10:46 9e028f
> > s img1 1 1.0 GB 0.0 MB 0.0 MB 2012-04-23 10:46 9e0290
> img1-sn1
> > s img1 2 1.0 GB 0.0 MB 0.0 MB 2012-04-23 10:47 9e0291
> img1-sn2
> > s img1 3 1.0 GB 0.0 MB 0.0 MB 2012-04-23 10:47 9e0292
> img1-sn3
> > img2 0 1.0 GB 0.0 MB 0.0 MB 2012-04-23 10:47 9e0442
> > [wujue.yht at v134092.sqa.cm4 ~]$ ./collie vdi tree
> > v1---(you are here)
> > img1---(you are here)-+-[2012-04-23 10:46]
> > |-[2012-04-23 10:47]
> > `-[2012-04-23 10:47]
> > img2---(you are here)
> > The snapshots will not display on one line, because all of snapshots
> belong
> > to base VDI now and there is no direct relation between snapshots. I am
> not
> > sure of this. Do we need display them on one line?
> >
> > Because the base VDI never be changed, the postion identified by 'you are
> > here' always follows base VDI after my change. Do we expect this?
>
> The problem is that your patch doesn't set VDI relationships
> correctly. 'parent_vdi_id' in struct sheepdog_inode should be the
> source vdi id, and 'child_vdi_id' should contain children vdi. If you
> create a new vdi (or snapshot) B from A, A is a parent of B.
>
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
vdi ID 709129
its parent ID 709128
no child
vdi ID 70912a
its parent ID 709128
no child
>
>
> > 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.
Thanks
Haiting
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.wpkg.org/pipermail/sheepdog/attachments/20120424/77c55540/attachment-0003.html>
More information about the sheepdog
mailing list