From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:51728) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YiJuv-0005ua-PM for qemu-devel@nongnu.org; Wed, 15 Apr 2015 05:47:34 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YiJus-0000CK-5z for qemu-devel@nongnu.org; Wed, 15 Apr 2015 05:47:33 -0400 Received: from mx1.redhat.com ([209.132.183.28]:54255) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YiJur-0000C5-Pb for qemu-devel@nongnu.org; Wed, 15 Apr 2015 05:47:30 -0400 Date: Wed, 15 Apr 2015 11:47:25 +0200 From: Kevin Wolf Message-ID: <20150415094725.GB4503@noname.redhat.com> References: <552897D1.7020300@suse.de> <20150414095735.GC4824@noname.redhat.com> <20150415045229.GA2952@localhost.localdomain> <20150415092629.GA4503@noname.redhat.com> <552E30B7.4000604@suse.de> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline In-Reply-To: <552E30B7.4000604@suse.de> 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: Andreas =?iso-8859-1?Q?F=E4rber?= Cc: Peter Maydell , Jeff Cody , qemu-devel , Stefan Hajnoczi Am 15.04.2015 um 11:34 hat Andreas F=E4rber geschrieben: > Am 15.04.2015 um 11:26 schrieb Kevin Wolf: > > 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, > >>>> > >>>> 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 comma= nd > >>>> line option to skip this one failing test? -x seems to be for grou= ps 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 (th= at'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 explici= t > >>> 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 assert= ion > >>> failures when using VHDX over blkdebug. Jeff, does the following fi= x > >>> 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 wor= ds: > >>> "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 bee= n > >> hidden): > >> > >> 1.) If bs->file supports zero init, we don't do any of this > >=20 > > I see. file does and blkdebug doesn't, so that's the crucial differen= ce. > >=20 > >> 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. > >=20 > > Right, I wasn't aware of this either any more. > >=20 > >> So it has been a latent bug in a hitherto rarely (if ever) exercised > >> path. > >=20 > > 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. >=20 > Might 059 (?) failure for -vmdk be another symptom of the same issue? 059 passes for me with vmdk. If it fails for you, can you please paste the output diff? Kevin