From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:39142) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YiHBY-0007sC-9p for qemu-devel@nongnu.org; Wed, 15 Apr 2015 02:52:33 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YiHBT-0000Iv-AS for qemu-devel@nongnu.org; Wed, 15 Apr 2015 02:52:32 -0400 Received: from mx1.redhat.com ([209.132.183.28]:45882) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YiHBT-0000Im-33 for qemu-devel@nongnu.org; Wed, 15 Apr 2015 02:52:27 -0400 Date: Wed, 15 Apr 2015 00:53:30 -0400 From: Jeff Cody Message-ID: <20150415045229.GA2952@localhost.localdomain> References: <552897D1.7020300@suse.de> <20150414095735.GC4824@noname.redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline In-Reply-To: <20150414095735.GC4824@noname.redhat.com> Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] Failing iotests in v2.3.0-rc2 / master List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Kevin Wolf Cc: Peter Maydell , Andreas =?iso-8859-1?Q?F=E4rber?= , Stefan Hajnoczi , qemu-devel On Tue, Apr 14, 2015 at 11:57:35AM +0200, Kevin Wolf wrote: > 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 = only. > >=20 > > Regards, > > Andreas > >=20 > > $ ./check -v -T -qcow -g quick > > [...] > > 001 6s ... [05:12:39] >=20 > qcow1 is just really slow. 001 passes for me, after 202 seconds (that's > on my SSD, YMMV). >=20 > > $ ./check -v -T -vhdx -g quick > > [...] > > 033 1s ... [04:06:09] [04:06:11] - output mismatch (see 033.ou= t.bad) >=20 > 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. >=20 > 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?") >=20 > 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 >=20 > --- a/block/vhdx.c > +++ b/block/vhdx.c > @@ -1285,7 +1285,7 @@ static coroutine_fn int vhdx_co_writev(BlockDrive= rState *bs, int64_t sector_num, > iov2.iov_base =3D 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 +=3D iov2.iov_len >> BDRV_SEC= TOR_BITS; > } > }