<div class="gmail_extra"><br><br></div>
<div class="gmail_quote">On Sat, Apr 21, 2012 at 4:56 AM, MORITA Kazutaka <span dir="ltr"><<a href="mailto:morita.kazutaka@gmail.com" target="_blank">morita.kazutaka@gmail.com</a>></span> wrote:<br>
<blockquote style="BORDER-LEFT:#ccc 1px solid;MARGIN:0px 0px 0px 0.8ex;PADDING-LEFT:1ex" class="gmail_quote">At Fri, 20 Apr 2012 14:40:26 +0800,<br>
<div>
<div class="h5"><a href="mailto:yaohaiting.wujue@gmail.com">yaohaiting.wujue@gmail.com</a> wrote:<br>><br>> From: HaiTing Yao <<a href="mailto:wujue.yht@taobao.com">wujue.yht@taobao.com</a>><br>><br>> When create snapshot for source VDI, the new created VDI used as source<br>
> VDI, and the old source VDI used as snapshot. This flow make users<br>> confused about VDI and snapshot relation. The snapshot metadata maybe is<br>> stored on multi-VDI, so need read multi VDIs inode to get snapshot list.<br>
><br>> When create snapshot, we does not need change new created VDI to source<br>> VDI. The source VDI just need use snapshot VDI ID as its object data ID.<br>><br>> Show one example.<br>><br>> Before modification:<br>
><br>>   Name        Id    Size    Used  Shared    Creation time   VDI id   Tag<br>> s v1           1   64 MB   20 MB  0.0 MB 2012-03-26 16:55   709128<br>> s v1           2   64 MB  0.0 MB   20 MB 2012-03-26 16:56   709129   sn3<br>
>   v1           3   64 MB  0.0 MB   20 MB 2012-03-26 16:56   70912a<br>><br>> After modification:<br>><br>>   Name        Id    Size    Used  Shared    Creation time   VDI id   Tag<br>>   v1           0   64 MB   20 MB  0.0 MB 2012-03-27 11:06   709128<br>
> s v1           1   64 MB  0.0 MB   20 MB 2012-03-27 11:06   709129<br>> s v1           2   64 MB  0.0 MB   20 MB 2012-03-27 11:07   70912a   sn3<br>><br>> Signed-off-by: HaiTing Yao <<a href="mailto:wujue.yht@taobao.com">wujue.yht@taobao.com</a>><br>
> ---<br>>  collie/common.c          |    2 +-<br>>  collie/vdi.c             |   33 ++++++++++++++++++++++-----------<br>>  include/sheepdog_proto.h |    6 ++++--<br>>  sheep/vdi.c              |   18 ++++++++++--------<br>
>  4 files changed, 37 insertions(+), 22 deletions(-)<br><br></div></div>Your patch breaks the relationship between VDI snapshots.<br>For example:<br>==<br> $ collie cluster format -c 1<br><br> $ qemu-img create sheepdog:test 4G<br>
 $ qemu-img snapshot -c tag1 sheepdog:test<br> $ qemu-img snapshot -c tag2 sheepdog:test<br> $ qemu-img snapshot -c tag3 sheepdog:test<br><br> $ qemu-img create sheepdog:test2 4G<br> $ qemu-img snapshot -c tag1 sheepdog:test2<br>
 $ qemu-img snapshot -c tag2 sheepdog:test2<br> $ qemu-io -c "write 0 512" sheepdog:test2:1<br> $ qemu-img snapshot -c tag3 sheepdog:test2<br><br> $ collie vdi tree<br>==<br><br>and the expected output is:<br>==<br>
 test---[2012-04-21 05:51]---[2012-04-21 05:51]---[2012-04-21 05:51]---(you are here)<br> test2---[2012-04-21 05:51]-+-[2012-04-21 05:51]---[2012-04-21 05:51]<br>                            `-[2012-04-21 05:51]---(you are here)<br>
==<br></blockquote>
<div> </div>
<div>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:</div>

<div> </div>
<div>void do_io_request(struct work *work)</div>
<div> </div>
<div>        dprintf("%x, %" PRIx64" , %u\n", opcode, oid, epoch);</div>
<div>       + hdr->flags = hdr->flags & ~SD_FLAG_CMD_CACHE;</div>
<div>        if (hdr->flags & SD_FLAG_CMD_RECOVERY)</div>
<div> </div>
<div>Then the display like this</div>
<div> </div>
<div>[wujue.yht@v134092.sqa.cm4 ~]$ clv<br>  Name        Id    Size    Used  Shared    Creation time   VDI id  Tag<br>  v1           0  1.0 GB  0.0 MB  0.0 MB 2012-04-23 10:45   709128  <br>  img1         0  1.0 GB  0.0 MB  0.0 MB 2012-04-23 10:46   9e028f  <br>
s img1         1  1.0 GB  0.0 MB  0.0 MB 2012-04-23 10:46   9e0290  img1-sn1<br>s img1         2  1.0 GB  0.0 MB  0.0 MB 2012-04-23 10:47   9e0291  img1-sn2<br>s img1         3  1.0 GB  0.0 MB  0.0 MB 2012-04-23 10:47   9e0292  img1-sn3<br>
  img2         0  1.0 GB  0.0 MB  0.0 MB 2012-04-23 10:47   9e0442  <br>[wujue.yht@v134092.sqa.cm4 ~]$ ./collie vdi tree<br>v1---(you are here)<br>img1---(you are here)-+-[2012-04-23 10:46]<br>                      |-[2012-04-23 10:47]<br>
                      `-[2012-04-23 10:47]<br>img2---(you are here)<br></div>
<div>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?</div>
<div> </div>
<div>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?</div>
<div> </div>
<blockquote style="BORDER-LEFT:#ccc 1px solid;MARGIN:0px 0px 0px 0.8ex;PADDING-LEFT:1ex" class="gmail_quote"><br>BTW, How about displaying the current Id as zero and removing VDI id<br>from the output of 'collie vdi list'?  VDI IDs are used for internal<br>
purpose only, so I think we don't need to display them here.  I'd like<br>to avoid changing the VDI structure if possible.<br></blockquote>
<div> </div>
<div>Yes, I also think VDI ID is for internal purpose and we need not to display here.  The   snap id of base VDI is zero now.</div>
<div> </div>
<blockquote style="BORDER-LEFT:#ccc 1px solid;MARGIN:0px 0px 0px 0.8ex;PADDING-LEFT:1ex" class="gmail_quote"><br>Thanks,<br><br>Kazutaka<br></blockquote>
<div> </div></div>
<div>BTW, since we change the inode structure, how about increse the SD_PROTO_VER?</div>
<div> </div>
<div>With this patch, the precious data can not be clued properly. If customers need use precious data, I can supply a tool to upgrade.</div>
<div> </div>
<div>Thanks</div>
<div>Haiting</div>
<div> </div>
<div class="gmail_extra"><br></div>