Am 05.09.2019 um 12:02 hat Peter Lieven geschrieben:
> Am 04.09.19 um 16:09 schrieb Kevin Wolf:
> > Am 03.09.2019 um 15:35 hat Peter Lieven geschrieben:
> > > qemu is currently not able to detect truncated vhdx image files.
> > > Add a basic check if all allocated blocks are reachable at open and
> > > report all errors during bdrv_co_check.
> > >
> > > Signed-off-by: Peter Lieven <p...@kamp.de>
> > > ---
> > > V3: - check for bdrv_getlength failure [Kevin]
> > > - use uint32_t for i [Kevin]
> > > - check for BAT entry overflow [Kevin]
> > > - break on !errcnt in second check
> > >
> > > V2: - add error reporting [Kevin]
> > > - use bdrv_getlength instead of bdrv_get_allocated_file_size [Kevin]
> > > - factor out BAT entry check and add error reporting for region
> > > overlaps
> > > - already check on vhdx_open
> > Something still seems to be wrong with this patch:
> >
> > 213 fail [15:50:13] [15:50:14] (last: 2s) output
> > mismatch (see 213.out.bad)
> > --- /home/kwolf/source/qemu/tests/qemu-iotests/213.out 2019-06-28
> > 14:19:50.065797707 +0200
> > +++ /home/kwolf/source/qemu/tests/qemu-iotests/213.out.bad
> > 2019-09-04 15:50:14.582053976 +0200
> > @@ -46,10 +46,8 @@
> > {"execute": "job-dismiss", "arguments": {"id": "job0"}}
> > {"return": {}}
> >
> > -image: TEST_IMG
> > -file format: IMGFMT
> > -virtual size: 32 MiB (33554432 bytes)
> > -cluster_size: 268435456
> > +qemu-img: VHDX BAT entry 0 offset points after end of file. Image has
> > probably been truncated.
> > +qemu-img: Could not open 'TEST_IMG': Could not open 'TEST_IMG':
> > Invalid argument
> >
> > === Invalid BlockdevRef ===
> >
> > I can reproduce this manually with the following qemu-img invocations.
> > It seems all three options must be given to reproduce the error:
> >
> > $ ./qemu-img create -f vhdx -o
> > block_size=268435456,subformat=fixed,block_state_zero=off /tmp/test.vhdx 32M
> > Formatting '/tmp/test.vhdx', fmt=vhdx size=33554432 log_size=1048576
> > block_size=268435456 subformat=fixed block_state_zero=off
> > $ ./qemu-img info /tmp/test.vhdx
> > qemu-img: VHDX BAT entry 0 offset points after end of file. Image has
> > probably been truncated.
> > qemu-img: Could not open '/tmp/test.vhdx': Could not open
> > '/tmp/test.vhdx': Invalid argument
> >
> > If I add the offsets to the error message (would probably nice to have),
> > I get:
> >
> > qemu-img: VHDX BAT entry 0 offset 8388608 points after end of file
> > (41943040). Image has probably been truncated.
> >
> > So it seems that the file is large enough to hold 32M + metadata, but we
> > don't increase the file size to hold a full block (256M). Is this a
> > problem in the way we create images or are partial blocks at the end
> > expected?
> >
> > Kevin
>
>
> A short look into the VHDX spec [1] seems to suggest that a VHDX File
> can only grow in Block increments.
>
> See page 8 in the definition of blocks: "Allocation of new space for a
> virtual hard disk that supports dynamic growth of the virtual hard
> disk file is done in fixes size units defined as blocks."
Then I guess we need to fix the creation of VHDX images before we can
apply this patch because otherwise qemu-iotests fails.
Hm... And probably ignore the error for a partial final block anyway to
maintain compatibility with images created by older QEMU versions.
Kevin
