| Message ID | 20150414095735.GC4824@noname.redhat.com |
|---|---|
| State | New |
| Headers | show |
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 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 > > --- a/block/vhdx.c > +++ b/block/vhdx.c > @@ -1285,7 +1285,7 @@ static coroutine_fn int vhdx_co_writev(BlockDriverState *bs, int64_t sector_num, > iov2.iov_base = 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 += iov2.iov_len >> BDRV_SECTOR_BITS; > } > }
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. Kevin
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
Am 15.04.2015 um 11:34 hat Andreas Färber 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ä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? 059 passes for me with vmdk. If it fails for you, can you please paste the output diff? Kevin
Am 15.04.2015 um 11:47 schrieb Kevin Wolf: > Am 15.04.2015 um 11:34 hat Andreas Färber 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ä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? > > 059 passes for me with vmdk. If it fails for you, can you please paste > the output diff? With v2.3.0-rc3: -raw: [ 1714s] 005 [02:45:31] [02:45:31] - output mismatch (see 005.out.bad) [ 1714s] --- /home/abuild/rpmbuild/BUILD/qemu-2.3.0-rc3/tests/qemu-iotests/005.out 2015-04-13 18:34:01.000000000 +0000 [ 1714s] +++ 005.out.bad 2015-04-15 02:45:31.540000000 +0000 [ 1714s] @@ -1,13 +1,12 @@ [ 1714s] QA output created by 005 [ 1714s] [ 1714s] creating large image [ 1714s] +qemu-img: TEST_DIR/t.IMGFMT: The image size is too large for file format 'IMGFMT' [ 1714s] Formatting 'TEST_DIR/t.IMGFMT', fmt=IMGFMT size=5368709120000 [ 1714s] [ 1714s] small read [ 1714s] -read 4096/4096 bytes at offset 1024 [ 1714s] -4 KiB, X ops; XX:XX:XX.X (XXX YYY/sec and XXX ops/sec) [ 1714s] +read failed: Input/output error [ 1714s] [ 1714s] small write [ 1714s] -wrote 4096/4096 bytes at offset 8192 [ 1714s] -4 KiB, X ops; XX:XX:XX.X (XXX YYY/sec and XXX ops/sec) [ 1714s] +write failed: Input/output error [ 1714s] *** done -qcow2: [ 1867s] 028 [02:47:55] [02:48:04] - output mismatch (see 028.out.bad) [ 1867s] --- /home/abuild/rpmbuild/BUILD/qemu-2.3.0-rc3/tests/qemu-iotests/028.out 2015-04-13 18:34:01.000000000 +0000 [ 1867s] +++ 028.out.bad 2015-04-15 02:48:04.908000000 +0000 [ 1867s] @@ -473,6 +473,14 @@ [ 1867s] (qemu) i[K[Din[K[D[Dinf[K[D[D[Dinfo[K[D[D[D[Dinfo [K[D[D[D[D[Dinfo b[K[D[D[D[D[D[Dinfo bl[K[D[D[D[D[D[D[Dinfo blo[K[D[D[D[D[D[D[D[Dinfo bloc[K[D[D[D[D[D[D[D[D[Dinfo block[K[D[D[D[D[D[D[D[D[D[Dinfo block-[K[D[D[D[D[D[D[D[D[D[D[Dinfo block-j[K[D[D[D[D[D[D[D[D[D[D[D[Dinfo block-jo[K[D[D[D[D[D[D[D[D[D[D[D[D[Dinfo block-job[K[D[D[D[D[D[D[D[D[D[D[D[D[D[Dinfo block-jobs[K [ 1867s] Type backup, device disk: Completed 0 of 4294968832 bytes, speed limit 0 bytes/s [ 1867s] i[K[Din[K[D[Dinf[K[D[D[Dinfo[K[D[D[D[Dinfo [K[D[D[D[D[Dinfo b[K[D[D[D[D[D[Dinfo bl[K[D[D[D[D[D[D[Dinfo blo[K[D[D[D[D[D[D[D[Dinfo bloc[K[D[D[D[D[D[D[D[D[Dinfo block[K[D[D[D[D[D[D[D[D[D[Dinfo block-[K[D[D[D[D[D[D[D[D[D[D[Dinfo block-j[K[D[D[D[D[D[D[D[D[D[D[D[Dinfo block-jo[K[D[D[D[D[D[D[D[D[D[D[D[D[Dinfo block-job[K[D[D[D[D[D[D[D[D[D[D[D[D[D[Dinfo block-jobs[K [ 1867s] +Type backup, device disk: Completed 0 of 4294968832 bytes, speed limit 0 bytes/s [ 1867s] +i[K[Din[K[D[Dinf[K[D[D[Dinfo[K[D[D[D[Dinfo [K[D[D[D[D[Dinfo b[K[D[D[D[D[D[Dinfo bl[K[D[D[D[D[D[D[Dinfo blo[K[D[D[D[D[D[D[D[Dinfo bloc[K[D[D[D[D[D[D[D[D[Dinfo block[K[D[D[D[D[D[D[D[D[D[Dinfo block-[K[D[D[D[D[D[D[D[D[D[D[Dinfo block-j[K[D[D[D[D[D[D[D[D[D[D[D[Dinfo block-jo[K[D[D[D[D[D[D[D[D[D[D[D[D[Dinfo block-job[K[D[D[D[D[D[D[D[D[D[D[D[D[D[Dinfo block-jobs[K [ 1867s] +Type backup, device disk: Completed 0 of 4294968832 bytes, speed limit 0 bytes/s [ 1867s] +i[K[Din[K[D[Dinf[K[D[D[Dinfo[K[D[D[D[Dinfo [K[D[D[D[D[Dinfo b[K[D[D[D[D[D[Dinfo bl[K[D[D[D[D[D[D[Dinfo blo[K[D[D[D[D[D[D[D[Dinfo bloc[K[D[D[D[D[D[D[D[D[Dinfo block[K[D[D[D[D[D[D[D[D[D[Dinfo block-[K[D[D[D[D[D[D[D[D[D[D[Dinfo block-j[K[D[D[D[D[D[D[D[D[D[D[D[Dinfo block-jo[K[D[D[D[D[D[D[D[D[D[D[D[D[Dinfo block-job[K[D[D[D[D[D[D[D[D[D[D[D[D[D[Dinfo block-jobs[K [ 1867s] +Type backup, device disk: Completed 0 of 4294968832 bytes, speed limit 0 bytes/s [ 1867s] +i[K[Din[K[D[Dinf[K[D[D[Dinfo[K[D[D[D[Dinfo [K[D[D[D[D[Dinfo b[K[D[D[D[D[D[Dinfo bl[K[D[D[D[D[D[D[Dinfo blo[K[D[D[D[D[D[D[D[Dinfo bloc[K[D[D[D[D[D[D[D[D[Dinfo block[K[D[D[D[D[D[D[D[D[D[Dinfo block-[K[D[D[D[D[D[D[D[D[D[D[Dinfo block-j[K[D[D[D[D[D[D[D[D[D[D[D[Dinfo block-jo[K[D[D[D[D[D[D[D[D[D[D[D[D[Dinfo block-job[K[D[D[D[D[D[D[D[D[D[D[D[D[D[Dinfo block-jobs[K [ 1867s] +Type backup, device disk: Completed 131072 of 4294968832 bytes, speed limit 0 bytes/s [ 1867s] +i[K[Din[K[D[Dinf[K[D[D[Dinfo[K[D[D[D[Dinfo [K[D[D[D[D[Dinfo b[K[D[D[D[D[D[Dinfo bl[K[D[D[D[D[D[D[Dinfo blo[K[D[D[D[D[D[D[D[Dinfo bloc[K[D[D[D[D[D[D[D[D[Dinfo block[K[D[D[D[D[D[D[D[D[D[Dinfo block-[K[D[D[D[D[D[D[D[D[D[D[Dinfo block-j[K[D[D[D[D[D[D[D[D[D[D[D[Dinfo block-jo[K[D[D[D[D[D[D[D[D[D[D[D[D[Dinfo block-job[K[D[D[D[D[D[D[D[D[D[D[D[D[D[Dinfo block-jobs[K [ 1867s] No active jobs [ 1867s] === IO: pattern 195 [ 1867s] read 512/512 bytes at offset 3221194240 -qed: [ 1946s] 028 [02:49:13] [02:49:23] - output mismatch (see 028.out.bad) [ 1946s] --- /home/abuild/rpmbuild/BUILD/qemu-2.3.0-rc3/tests/qemu-iotests/028.out 2015-04-13 18:34:01.000000000 +0000 [ 1946s] +++ 028.out.bad 2015-04-15 02:49:23.444000000 +0000 [ 1946s] @@ -473,6 +473,14 @@ [ 1946s] (qemu) i[K[Din[K[D[Dinf[K[D[D[Dinfo[K[D[D[D[Dinfo [K[D[D[D[D[Dinfo b[K[D[D[D[D[D[Dinfo bl[K[D[D[D[D[D[D[Dinfo blo[K[D[D[D[D[D[D[D[Dinfo bloc[K[D[D[D[D[D[D[D[D[Dinfo block[K[D[D[D[D[D[D[D[D[D[Dinfo block-[K[D[D[D[D[D[D[D[D[D[D[Dinfo block-j[K[D[D[D[D[D[D[D[D[D[D[D[Dinfo block-jo[K[D[D[D[D[D[D[D[D[D[D[D[D[Dinfo block-job[K[D[D[D[D[D[D[D[D[D[D[D[D[D[Dinfo block-jobs[K [ 1946s] Type backup, device disk: Completed 0 of 4294968832 bytes, speed limit 0 bytes/s [ 1946s] i[K[Din[K[D[Dinf[K[D[D[Dinfo[K[D[D[D[Dinfo [K[D[D[D[D[Dinfo b[K[D[D[D[D[D[Dinfo bl[K[D[D[D[D[D[D[Dinfo blo[K[D[D[D[D[D[D[D[Dinfo bloc[K[D[D[D[D[D[D[D[D[Dinfo block[K[D[D[D[D[D[D[D[D[D[Dinfo block-[K[D[D[D[D[D[D[D[D[D[D[Dinfo block-j[K[D[D[D[D[D[D[D[D[D[D[D[Dinfo block-jo[K[D[D[D[D[D[D[D[D[D[D[D[D[Dinfo block-job[K[D[D[D[D[D[D[D[D[D[D[D[D[D[Dinfo block-jobs[K [ 1946s] +Type backup, device disk: Completed 0 of 4294968832 bytes, speed limit 0 bytes/s [ 1946s] +i[K[Din[K[D[Dinf[K[D[D[Dinfo[K[D[D[D[Dinfo [K[D[D[D[D[Dinfo b[K[D[D[D[D[D[Dinfo bl[K[D[D[D[D[D[D[Dinfo blo[K[D[D[D[D[D[D[D[Dinfo bloc[K[D[D[D[D[D[D[D[D[Dinfo block[K[D[D[D[D[D[D[D[D[D[Dinfo block-[K[D[D[D[D[D[D[D[D[D[D[Dinfo block-j[K[D[D[D[D[D[D[D[D[D[D[D[Dinfo block-jo[K[D[D[D[D[D[D[D[D[D[D[D[D[Dinfo block-job[K[D[D[D[D[D[D[D[D[D[D[D[D[D[Dinfo block-jobs[K [ 1946s] +Type backup, device disk: Completed 0 of 4294968832 bytes, speed limit 0 bytes/s [ 1946s] +i[K[Din[K[D[Dinf[K[D[D[Dinfo[K[D[D[D[Dinfo [K[D[D[D[D[Dinfo b[K[D[D[D[D[D[Dinfo bl[K[D[D[D[D[D[D[Dinfo blo[K[D[D[D[D[D[D[D[Dinfo bloc[K[D[D[D[D[D[D[D[D[Dinfo block[K[D[D[D[D[D[D[D[D[D[Dinfo block-[K[D[D[D[D[D[D[D[D[D[D[Dinfo block-j[K[D[D[D[D[D[D[D[D[D[D[D[Dinfo block-jo[K[D[D[D[D[D[D[D[D[D[D[D[D[Dinfo block-job[K[D[D[D[D[D[D[D[D[D[D[D[D[D[Dinfo block-jobs[K [ 1946s] +Type backup, device disk: Completed 0 of 4294968832 bytes, speed limit 0 bytes/s [ 1946s] +i[K[Din[K[D[Dinf[K[D[D[Dinfo[K[D[D[D[Dinfo [K[D[D[D[D[Dinfo b[K[D[D[D[D[D[Dinfo bl[K[D[D[D[D[D[D[Dinfo blo[K[D[D[D[D[D[D[D[Dinfo bloc[K[D[D[D[D[D[D[D[D[Dinfo block[K[D[D[D[D[D[D[D[D[D[Dinfo block-[K[D[D[D[D[D[D[D[D[D[D[Dinfo block-j[K[D[D[D[D[D[D[D[D[D[D[D[Dinfo block-jo[K[D[D[D[D[D[D[D[D[D[D[D[D[Dinfo block-job[K[D[D[D[D[D[D[D[D[D[D[D[D[D[Dinfo block-jobs[K [ 1946s] +Type backup, device disk: Completed 131072 of 4294968832 bytes, speed limit 0 bytes/s [ 1946s] +i[K[Din[K[D[Dinf[K[D[D[Dinfo[K[D[D[D[Dinfo [K[D[D[D[D[Dinfo b[K[D[D[D[D[D[Dinfo bl[K[D[D[D[D[D[D[Dinfo blo[K[D[D[D[D[D[D[D[Dinfo bloc[K[D[D[D[D[D[D[D[D[Dinfo block[K[D[D[D[D[D[D[D[D[D[Dinfo block-[K[D[D[D[D[D[D[D[D[D[D[Dinfo block-j[K[D[D[D[D[D[D[D[D[D[D[D[Dinfo block-jo[K[D[D[D[D[D[D[D[D[D[D[D[D[Dinfo block-job[K[D[D[D[D[D[D[D[D[D[D[D[D[D[Dinfo block-jobs[K [ 1946s] No active jobs [ 1946s] === IO: pattern 195 [ 1946s] read 512/512 bytes at offset 3221194240 -vmdk: [ 2125s] 059 [02:52:18] [02:52:22] - output mismatch (see 059.out.bad) [ 2125s] --- /home/abuild/rpmbuild/BUILD/qemu-2.3.0-rc3/tests/qemu-iotests/059.out 2015-04-13 18:34:01.000000000 +0000 [ 2125s] +++ 059.out.bad 2015-04-15 02:52:22.364000000 +0000 [ 2125s] @@ -2264,76 +2264,14 @@ [ 2125s] 512 bytes, X ops; XX:XX:XX.X (XXX YYY/sec and XXX ops/sec) [ 2125s] [ 2125s] === Testing 4TB monolithicFlat creation and IO === [ 2125s] +qemu-img: TEST_DIR/iotest-version3.IMGFMT: Could not truncate file: File too large [ 2125s] Formatting 'TEST_DIR/iotest-version3.IMGFMT', fmt=IMGFMT size=4398046511104 [ 2125s] image: TEST_DIR/iotest-version3.IMGFMT [ 2125s] file format: IMGFMT [ 2125s] -virtual size: 4.0T (4398046511104 bytes) [ 2125s] -wrote 512/512 bytes at offset 966367641600 [ 2125s] -512 bytes, X ops; XX:XX:XX.X (XXX YYY/sec and XXX ops/sec) [ 2125s] -e100000000: 0a 0a 0a 0a 0a 0a 0a 0a 0a 0a 0a 0a 0a 0a 0a 0a ................ [ 2125s] -e100000010: 0a 0a 0a 0a 0a 0a 0a 0a 0a 0a 0a 0a 0a 0a 0a 0a ................ [ 2125s] -e100000020: 0a 0a 0a 0a 0a 0a 0a 0a 0a 0a 0a 0a 0a 0a 0a 0a ................ [ 2125s] -e100000030: 0a 0a 0a 0a 0a 0a 0a 0a 0a 0a 0a 0a 0a 0a 0a 0a ................ [ 2125s] -e100000040: 0a 0a 0a 0a 0a 0a 0a 0a 0a 0a 0a 0a 0a 0a 0a 0a ................ [ 2125s] -e100000050: 0a 0a 0a 0a 0a 0a 0a 0a 0a 0a 0a 0a 0a 0a 0a 0a ................ [ 2125s] -e100000060: 0a 0a 0a 0a 0a 0a 0a 0a 0a 0a 0a 0a 0a 0a 0a 0a ................ [ 2125s] -e100000070: 0a 0a 0a 0a 0a 0a 0a 0a 0a 0a 0a 0a 0a 0a 0a 0a ................ [ 2125s] -e100000080: 0a 0a 0a 0a 0a 0a 0a 0a 0a 0a 0a 0a 0a 0a 0a 0a ................ [ 2125s] -e100000090: 0a 0a 0a 0a 0a 0a 0a 0a 0a 0a 0a 0a 0a 0a 0a 0a ................ [ 2125s] -e1000000a0: 0a 0a 0a 0a 0a 0a 0a 0a 0a 0a 0a 0a 0a 0a 0a 0a ................ [ 2125s] -e1000000b0: 0a 0a 0a 0a 0a 0a 0a 0a 0a 0a 0a 0a 0a 0a 0a 0a ................ [ 2125s] -e1000000c0: 0a 0a 0a 0a 0a 0a 0a 0a 0a 0a 0a 0a 0a 0a 0a 0a ................ [ 2125s] -e1000000d0: 0a 0a 0a 0a 0a 0a 0a 0a 0a 0a 0a 0a 0a 0a 0a 0a ................ [ 2125s] -e1000000e0: 0a 0a 0a 0a 0a 0a 0a 0a 0a 0a 0a 0a 0a 0a 0a 0a ................ [ 2125s] -e1000000f0: 0a 0a 0a 0a 0a 0a 0a 0a 0a 0a 0a 0a 0a 0a 0a 0a ................ [ 2125s] -e100000100: 0a 0a 0a 0a 0a 0a 0a 0a 0a 0a 0a 0a 0a 0a 0a 0a ................ [ 2125s] -e100000110: 0a 0a 0a 0a 0a 0a 0a 0a 0a 0a 0a 0a 0a 0a 0a 0a ................ [ 2125s] -e100000120: 0a 0a 0a 0a 0a 0a 0a 0a 0a 0a 0a 0a 0a 0a 0a 0a ................ [ 2125s] -e100000130: 0a 0a 0a 0a 0a 0a 0a 0a 0a 0a 0a 0a 0a 0a 0a 0a ................ [ 2125s] -e100000140: 0a 0a 0a 0a 0a 0a 0a 0a 0a 0a 0a 0a 0a 0a 0a 0a ................ [ 2125s] -e100000150: 0a 0a 0a 0a 0a 0a 0a 0a 0a 0a 0a 0a 0a 0a 0a 0a ................ [ 2125s] -e100000160: 0a 0a 0a 0a 0a 0a 0a 0a 0a 0a 0a 0a 0a 0a 0a 0a ................ [ 2125s] -e100000170: 0a 0a 0a 0a 0a 0a 0a 0a 0a 0a 0a 0a 0a 0a 0a 0a ................ [ 2125s] -e100000180: 0a 0a 0a 0a 0a 0a 0a 0a 0a 0a 0a 0a 0a 0a 0a 0a ................ [ 2125s] -e100000190: 0a 0a 0a 0a 0a 0a 0a 0a 0a 0a 0a 0a 0a 0a 0a 0a ................ [ 2125s] -e1000001a0: 0a 0a 0a 0a 0a 0a 0a 0a 0a 0a 0a 0a 0a 0a 0a 0a ................ [ 2125s] -e1000001b0: 0a 0a 0a 0a 0a 0a 0a 0a 0a 0a 0a 0a 0a 0a 0a 0a ................ [ 2125s] -e1000001c0: 0a 0a 0a 0a 0a 0a 0a 0a 0a 0a 0a 0a 0a 0a 0a 0a ................ [ 2125s] -e1000001d0: 0a 0a 0a 0a 0a 0a 0a 0a 0a 0a 0a 0a 0a 0a 0a 0a ................ [ 2125s] -e1000001e0: 0a 0a 0a 0a 0a 0a 0a 0a 0a 0a 0a 0a 0a 0a 0a 0a ................ [ 2125s] -e1000001f0: 0a 0a 0a 0a 0a 0a 0a 0a 0a 0a 0a 0a 0a 0a 0a 0a ................ [ 2125s] -e100000200: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ [ 2125s] -e100000210: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ [ 2125s] -e100000220: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ [ 2125s] -e100000230: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ [ 2125s] -e100000240: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ [ 2125s] -e100000250: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ [ 2125s] -e100000260: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ [ 2125s] -e100000270: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ [ 2125s] -e100000280: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ [ 2125s] -e100000290: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ [ 2125s] -e1000002a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ [ 2125s] -e1000002b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ [ 2125s] -e1000002c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ [ 2125s] -e1000002d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ [ 2125s] -e1000002e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ [ 2125s] -e1000002f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ [ 2125s] -e100000300: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ [ 2125s] -e100000310: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ [ 2125s] -e100000320: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ [ 2125s] -e100000330: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ [ 2125s] -e100000340: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ [ 2125s] -e100000350: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ [ 2125s] -e100000360: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ [ 2125s] -e100000370: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ [ 2125s] -e100000380: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ [ 2125s] -e100000390: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ [ 2125s] -e1000003a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ [ 2125s] -e1000003b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ [ 2125s] -e1000003c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ [ 2125s] -e1000003d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ [ 2125s] -e1000003e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ [ 2125s] -e1000003f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ [ 2125s] -read 1024/1024 bytes at offset 966367641600 [ 2125s] -1 KiB, X ops; XX:XX:XX.X (XXX YYY/sec and XXX ops/sec) [ 2125s] +virtual size: 16G (17179869184 bytes) [ 2125s] +cluster_size: 65536 [ 2125s] +qemu-io: can't open device /home/abuild/rpmbuild/BUILD/qemu-2.3.0-rc3/tests/qemu-iotests/scratch/iotest-version3.vmdk: VMDK version 3 must be read only [ 2125s] +no file open, try 'help open' [ 2125s] +qemu-io: can't open device /home/abuild/rpmbuild/BUILD/qemu-2.3.0-rc3/tests/qemu-iotests/scratch/iotest-version3.vmdk: VMDK version 3 must be read only [ 2125s] +no file open, try 'help open' [ 2125s] *** done https://build.opensuse.org/build/Virtualization/openSUSE_Factory/x86_64/qemu-testsuite/_log Regards, Andreas
On Tue, Apr 14, 2015 at 11:57:35AM +0200, Kevin Wolf wrote: [snip] > --- a/block/vhdx.c > +++ b/block/vhdx.c > @@ -1285,7 +1285,7 @@ static coroutine_fn int vhdx_co_writev(BlockDriverState *bs, int64_t sector_num, > iov2.iov_base = 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 += iov2.iov_len >> BDRV_SECTOR_BITS; > } > } acked-by: Jeff Cody <jcody@redhat.com>
--- a/block/vhdx.c +++ b/block/vhdx.c @@ -1285,7 +1285,7 @@ static coroutine_fn int vhdx_co_writev(BlockDriverState *bs, int64_t sector_num, iov2.iov_base = 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 += iov2.iov_len >> BDRV_SECTOR_BITS; } }