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ä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 > > 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.
Might 059 (?) failure for -vmdk be another symptom of the same issue? Thanks, Andreas -- SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Felix Imendörffer, Jane Smithard, Jennifer Guild, Dilip Upmanyu, Graham Norton; HRB 21284 (AG Nürnberg)
