[sheepdog] Call to sd_truncate()

[Hadrien KOHL]

2013/12/12 Liu Yuan <namei.unix at gmail.com>

> On Thu, Dec 12, 2013 at 12:25:52PM +0100, Hadrien KOHL wrote:
> > I just sent the question to the qemu developer mailing list. But as I
> did,
> > I remembered this sd_truncate is also called
> > from  sd_co_writev(BlockDriverState *bs, int64_t sector_num, int
> > nb_sectors, QEMUIOVector *qiov):
> >
> > static coroutine_fn int sd_co_writev(BlockDriverState *bs, int64_t
> > sector_num,
> >                         int nb_sectors, QEMUIOVector *qiov)
> > {
> >     SheepdogAIOCB *acb;
> >      int ret;
> >
> >     if (bs->growable && sector_num + nb_sectors > bs->total_sectors) {
> >         ret = sd_truncate(bs, (sector_num + nb_sectors) *
> BDRV_SECTOR_SIZE);
> >         if (ret < 0) {
> >             return ret;
> >         }
>
> From the code, so if growable is true, seems that sheepdog support
> automatic
> grow of volume. So my last email about 'can't resize live VM' is wrong.
>
> By a simply glance of the code, seems that bs->growable is set by qcow2.c,
> which
> indicate that this might be a feature from qcow2 format.
>
> >         bs->total_sectors = sector_num + nb_sectors;
> >     }
> >
> >     acb = sd_aio_setup(bs, qiov, sector_num, nb_sectors);
> >     acb->aio_done_func = sd_write_done;
> >     acb->aiocb_type = AIOCB_WRITE_UDATA;
> >
> >     ret = sd_co_rw_vector(acb);
> > ...
> > }
> >
> > This function is mapped to bdrv_co_writev in the qemu driver.
> > Looking at the test in this function, the only way a shrink could happen
> -
> > I guess - is if the units in sector_num and nb_sectors are inconsistent
> > (esp since there's a conversion to "BDRV_SECTOR_SIZE") in relation to
> > bs->total_sectors.
> > I am using qcow2 file format and created the image with qemu-img -t qcow2
> > create sheepdog:name. Could it be related?
>
> I think this might be a bug about running qcow2 in sheepdog, but I can't
> figure
> out what is the problem by statically reviewing the code. Is there a
> reliable
> way to reproduce it?
>

Here is a way to reproduce:

First I create a test image. Then I boot (here using gentoo live cd).

# qemu-img create -f qcow2 sheepdog:test 10G
Formatting 'sheepdog:test', fmt=qcow2 size=10737418240 encryption=off
cluster_size=65536 lazy_refcounts=off
# 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 172.16.0.11:0

Then once logged in the machine via vnc:
# mkfs.ext4 /dev/vda
# mkdir /mnt/vda

Then I start receiving:

qemu-system-x86_64: shrinking is not supported
qemu-system-x86_64: shrinking is not supported
qemu-system-x86_64: shrinking is not supported
qemu-system-x86_64: shrinking is not supported
qemu-system-x86_64: shrinking is not supported
qemu-system-x86_64: shrinking is not supported
qemu-system-x86_64: shrinking is not supported
qemu-system-x86_64: shrinking is not supported

And IO buffer errors on the guest:

Buffer I/O error on device vda, logical block XXXXXXX

Hadrien


> Thanks
> Yuan
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.wpkg.org/pipermail/sheepdog/attachments/20131212/0fe0a2cf/attachment-0004.html>