Re: [Qemu-devel] Failing iotests in v2.3.0-rc2 / master

[Kevin Wolf <kwolf@redhat.com>]

Am 11.04.2015 um 05:41 hat Andreas Färber geschrieben:
> Hi,
> 
> 001 seems to hang for -qcow (or is not reasonably "quick": >5 min).
> 
> 033 is failing for -vhdx.
> 
> (Note that `make check-block` only tests -qcow2, so didn't uncover
> either of them.)
> 
> Given a failing test, am I seeing correctly that there is no command
> line option to skip this one failing test? -x seems to be for groups only.
> 
> Regards,
> Andreas
> 
> $ ./check -v -T -qcow -g quick
> [...]
> 001 6s ...        [05:12:39]

qcow1 is just really slow. 001 passes for me, after 202 seconds (that's
on my SSD, YMMV).

> $ ./check -v -T -vhdx -g quick
> [...]
> 033 1s ...        [04:06:09] [04:06:11] - output mismatch (see 033.out.bad)

This seems to be because blkdebug doesn't implement .bdrv_truncate.
Currently the test case isn't suitable for VHDX, which uses explicit
bdrv_truncate() calls to grow the image file. I'll send a patch for
blkdebug to allow this.

However, it seems that there is another problem which causes assertion
failures when using VHDX over blkdebug. Jeff, does the following fix
make sense to you? (I think it does, but I don't understand yet why the
assertion failure is only triggered with blkdebug - or in other words:
"how could this ever work?")

Kevin

--- a/block/vhdx.c
+++ b/block/vhdx.c
@@ -1285,7 +1285,7 @@ static coroutine_fn int vhdx_co_writev(BlockDriverState *bs, int64_t sector_num,
                         iov2.iov_base = qemu_blockalign(bs, iov2.iov_len);
                         memset(iov2.iov_base, 0, iov2.iov_len);
                         qemu_iovec_concat_iov(&hd_qiov, &iov2, 1, 0,
-                                              sinfo.block_offset);
+                                              iov2.iov_len);
                         sectors_to_write += iov2.iov_len >> BDRV_SECTOR_BITS;
                     }
                 }