From: Kevin Wolf <kwolf@redhat.com>
To: Peter Lieven <pl@kamp.de>
Cc: codyprime@gmail.com, mreitz@redhat.com, jhf@kamp.de,
qemu-block@nongnu.org, qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] [PATCH V3] block/vhdx: add check for truncated image files
Date: Wed, 4 Sep 2019 16:09:49 +0200 [thread overview]
Message-ID: <20190904140949.GC21246@localhost.localdomain> (raw)
In-Reply-To: <20190903133524.11755-1-pl@kamp.de>
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 <pl@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
next prev parent reply other threads:[~2019-09-04 14:11 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-09-03 13:35 [Qemu-devel] [PATCH V3] block/vhdx: add check for truncated image files Peter Lieven
2019-09-04 14:09 ` Kevin Wolf [this message]
2019-09-05 9:49 ` Peter Lieven
2019-09-05 10:02 ` Peter Lieven
2019-09-10 11:15 ` Kevin Wolf
2019-09-10 11:49 ` Peter Lieven
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20190904140949.GC21246@localhost.localdomain \
--to=kwolf@redhat.com \
--cc=codyprime@gmail.com \
--cc=jhf@kamp.de \
--cc=mreitz@redhat.com \
--cc=pl@kamp.de \
--cc=qemu-block@nongnu.org \
--cc=qemu-devel@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).