From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:45419) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YiJah-0006B3-RA for qemu-devel@nongnu.org; Wed, 15 Apr 2015 05:26:43 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YiJac-0000eQ-MN for qemu-devel@nongnu.org; Wed, 15 Apr 2015 05:26:39 -0400 Received: from mx1.redhat.com ([209.132.183.28]:45472) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YiJac-0000e0-G3 for qemu-devel@nongnu.org; Wed, 15 Apr 2015 05:26:34 -0400 Date: Wed, 15 Apr 2015 11:26:29 +0200 From: Kevin Wolf Message-ID: <20150415092629.GA4503@noname.redhat.com> References: <552897D1.7020300@suse.de> <20150414095735.GC4824@noname.redhat.com> <20150415045229.GA2952@localhost.localdomain> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline In-Reply-To: <20150415045229.GA2952@localhost.localdomain> 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: Jeff Cody Cc: Peter Maydell , Andreas =?iso-8859-1?Q?F=E4rber?= , Stefan Hajnoczi , qemu-devel Am 15.04.2015 um 06:53 hat Jeff Cody geschrieben: > 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 comman= d > > > line option to skip this one failing test? -x seems to be for group= s 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.= out.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 assertio= n > > 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 t= he > > assertion failure is only triggered with blkdebug - or in other words= : > > "how could this ever work?") > >=20 > > Kevin >=20 > Kevin, >=20 > 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. >=20 > There are two reasons I think we haven't seen this issue (it has been > hidden): >=20 > 1.) If bs->file supports zero init, we don't do any of this I see. file does and blkdebug doesn't, so that's the crucial difference. > 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. Right, I wasn't aware of this either any more. > So it has been a latent bug in a hitherto rarely (if ever) exercised > path. Thanks for your explanation, it's clear to me now what's going on. I'll send out the patches (for both blkdebug and vhdx) right away. You can either pick up the vhdx one, or just give your Acked-by and then I'll merge it through my block tree. Kevin