From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([2001:4830:134:3::10]:59152)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <kwolf@redhat.com>) id 1YhxbD-0005I2-Ko
	for qemu-devel@nongnu.org; Tue, 14 Apr 2015 05:57:47 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <kwolf@redhat.com>) id 1Yhxb9-0005jS-EX
	for qemu-devel@nongnu.org; Tue, 14 Apr 2015 05:57:43 -0400
Received: from mx1.redhat.com ([209.132.183.28]:34934)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <kwolf@redhat.com>) id 1Yhxb9-0005jK-91
	for qemu-devel@nongnu.org; Tue, 14 Apr 2015 05:57:39 -0400
Date: Tue, 14 Apr 2015 11:57:35 +0200
From: Kevin Wolf <kwolf@redhat.com>
Message-ID: <20150414095735.GC4824@noname.redhat.com>
References: <552897D1.7020300@suse.de>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
In-Reply-To: <552897D1.7020300@suse.de>
Content-Transfer-Encoding: quoted-printable
Subject: Re: [Qemu-devel] Failing iotests in v2.3.0-rc2 / master
List-Id: <qemu-devel.nongnu.org>
List-Unsubscribe: <https://lists.nongnu.org/mailman/options/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.nongnu.org/archive/html/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <https://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Andreas =?iso-8859-1?Q?F=E4rber?= <afaerber@suse.de>
Cc: Peter Maydell <peter.maydell@linaro.org>, Jeff Cody <jcody@redhat.com>, qemu-devel <qemu-devel@nongnu.org>, Stefan Hajnoczi <stefanha@redhat.com>

Am 11.04.2015 um 05:41 hat Andreas F=E4rber geschrieben:
> Hi,
>=20
> 001 seems to hang for -qcow (or is not reasonably "quick": >5 min).
>=20
> 033 is failing for -vhdx.
>=20
> (Note that `make check-block` only tests -qcow2, so didn't uncover
> either of them.)
>=20
> 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 on=
ly.
>=20
> Regards,
> Andreas
>=20
> $ ./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(BlockDriverS=
tate *bs, int64_t sector_num,
                         iov2.iov_base =3D qemu_blockalign(bs, iov2.iov_l=
en);
                         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 +=3D iov2.iov_len >> BDRV_SECTO=
R_BITS;
                     }
                 }