[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] Failing iotests in v2.3.0-rc2 / master
From: |
Jeff Cody |
Subject: |
Re: [Qemu-devel] Failing iotests in v2.3.0-rc2 / master |
Date: |
Wed, 15 Apr 2015 00:53:30 -0400 |
User-agent: |
Mutt/1.5.21 (2010-09-15) |
On Tue, Apr 14, 2015 at 11:57:35AM +0200, Kevin Wolf wrote:
> 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
Kevin,
Yes, looking at that fix it makes sense - we are wanting to pad the
back part of the block after the actual data with zeros. That back
length should be (block size - (bytes avail + block offset)), which is
iov2.iov_len.
There are two reasons I think we haven't seen this issue (it has been
hidden):
1.) If bs->file supports zero init, we don't do any of this
2.) This is done for the case when the existing BAT state is
PAYLOAD_BLOCK_ZERO. Until recently (commit 30af51c), we didn't
create VHDX files with blocks in the PAYLOAD_BLOCK_ZERO state.
So it has been a latent bug in a hitherto rarely (if ever) exercised
path.
Jeff
>
> --- 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;
> }
> }
Re: [Qemu-devel] Failing iotests in v2.3.0-rc2 / master, Jeff Cody, 2015/04/15