<div dir="ltr">I noticed something that is comforting me in the idea that the sd_co_writev is doing something wrong.<div>When sending bytes to a file on the filesystem of the guest, I am getting error alsmost right away, but if I do it again it take some times to appear. </div>
<div>It seems that somehow, the bytes sent are allocated anyways and that no errors is raised until cow2/sheepdog needs to allocate space again. Does that make sense? </div><div><br></div><div>I dd'ed directly in the vda block device several times and I noticed that error are coming precisely after the same amount of time the last errors appeared. </div>
<div><br></div><div>Hope that helps.</div><div><br></div><div>Hadrien Kohl<br><br><div class="gmail_quote">---------- Forwarded message ----------<br>From: <b class="gmail_sendername">Hadrien KOHL</b> <span dir="ltr"><<a href="mailto:hadrien.kohl@gmail.com">hadrien.kohl@gmail.com</a>></span><br>
Date: 2013/12/12<br>Subject: Re: [sheepdog] Call to sd_truncate()<br>To: Liu Yuan <<a href="mailto:namei.unix@gmail.com">namei.unix@gmail.com</a>><br>Cc: sheepdog <<a href="mailto:sheepdog@lists.wpkg.org">sheepdog@lists.wpkg.org</a>><br>
<br><br><div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote"><div><div class="h5">2013/12/12 Liu Yuan <span dir="ltr"><<a href="mailto:namei.unix@gmail.com" target="_blank">namei.unix@gmail.com</a>></span><br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div>On Thu, Dec 12, 2013 at 12:25:52PM +0100, Hadrien KOHL wrote:<br>
> I just sent the question to the qemu developer mailing list. But as I did,<br>
> I remembered this sd_truncate is also called<br>
> from sd_co_writev(BlockDriverState *bs, int64_t sector_num, int<br>
> nb_sectors, QEMUIOVector *qiov):<br>
><br>
> static coroutine_fn int sd_co_writev(BlockDriverState *bs, int64_t<br>
> sector_num,<br>
> int nb_sectors, QEMUIOVector *qiov)<br>
> {<br>
> SheepdogAIOCB *acb;<br>
> int ret;<br>
><br>
> if (bs->growable && sector_num + nb_sectors > bs->total_sectors) {<br>
> ret = sd_truncate(bs, (sector_num + nb_sectors) * BDRV_SECTOR_SIZE);<br>
> if (ret < 0) {<br>
> return ret;<br>
> }<br>
<br>
</div>From the code, so if growable is true, seems that sheepdog support automatic<br>
grow of volume. So my last email about 'can't resize live VM' is wrong.<br>
<br>
By a simply glance of the code, seems that bs->growable is set by qcow2.c, which<br>
indicate that this might be a feature from qcow2 format.<br>
<div><br>
> bs->total_sectors = sector_num + nb_sectors;<br>
> }<br>
><br>
> acb = sd_aio_setup(bs, qiov, sector_num, nb_sectors);<br>
> acb->aio_done_func = sd_write_done;<br>
> acb->aiocb_type = AIOCB_WRITE_UDATA;<br>
><br>
> ret = sd_co_rw_vector(acb);<br>
> ...<br>
> }<br>
><br>
> This function is mapped to bdrv_co_writev in the qemu driver.<br>
> Looking at the test in this function, the only way a shrink could happen -<br>
> I guess - is if the units in sector_num and nb_sectors are inconsistent<br>
> (esp since there's a conversion to "BDRV_SECTOR_SIZE") in relation to<br>
> bs->total_sectors.<br>
> I am using qcow2 file format and created the image with qemu-img -t qcow2<br>
> create sheepdog:name. Could it be related?<br>
<br>
</div>I think this might be a bug about running qcow2 in sheepdog, but I can't figure<br>
out what is the problem by statically reviewing the code. Is there a reliable<br>
way to reproduce it?<br></blockquote><div><br></div></div></div><div>Here is a way to reproduce: </div><div><br></div><div>First I create a test image. Then I boot (here using gentoo live cd).</div><div><br></div><div># qemu-img create -f qcow2 sheepdog:test 10G<br>
</div><div>Formatting 'sheepdog:test', fmt=qcow2 size=10737418240 encryption=off cluster_size=65536 lazy_refcounts=off<br></div><div># qemu-system-x86_64 -drive file=sheepdog:127.0.0.1:7000:test,if=none,id=virtio-disk0,format=qcow2,cache=writeback -cdrom /vm/iso/install-amd64-minimal-20131010.iso -boot cd -m 256 -name test -vnc <a href="http://172.16.0.11:0" target="_blank">172.16.0.11:0</a><br>
</div><div><br></div><div>Then once logged in the machine via vnc:</div><div># mkfs.ext4 /dev/vda</div><div># mkdir /mnt/vda<br></div><div><br></div><div>Then I start receiving:</div><div class="im"><div><br></div><div><div>
qemu-system-x86_64: shrinking is not supported</div>
<div>qemu-system-x86_64: shrinking is not supported</div><div>qemu-system-x86_64: shrinking is not supported</div><div>qemu-system-x86_64: shrinking is not supported</div><div>qemu-system-x86_64: shrinking is not supported</div>
<div>qemu-system-x86_64: shrinking is not supported</div><div>qemu-system-x86_64: shrinking is not supported</div><div>qemu-system-x86_64: shrinking is not supported</div></div><div><br></div></div><div>And IO buffer errors on the guest:</div>
<div><br></div><div>Buffer I/O error on device vda, logical block XXXXXXX</div><div><br></div><div>Hadrien</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
Thanks<br>
<span><font color="#888888">Yuan<br>
</font></span></blockquote></div><br></div></div>
</div><br></div></div>