On Mon, Oct 3, 2011 at 2:01 PM, nicolas prochazka
<prochazka.nico...@gmail.com> wrote:
> sorry to bother you, i send dump of two qemu-io command .
> What can I do with this result ?
The qemu-io -c read command was successful. This means that the I/O
error was triggered by the specific request that qemu-img convert
issued, not a general problem with the image file. It also means the
image itself may not be corrupted at all - this could just be a bug in
the qemu-img convert code.
Thanks for collecting the qemu-io -c map output. The image file has
clusters allocated around the offset where your I/O error was
reported. There's nothing unusal in this output:
[ 2768175104] 128/ 36536448 sectors allocated at
offset 2.578 GiB (1)
[ **2768240640**] 128/ 36536320 sectors
allocated at offset 2.578 GiB (1)
[ 2768306176] 128/ 36536192 sectors allocated at
offset 2.578 GiB (1)
[ 2768371712] 128/ 36536064 sectors allocated at
offset 2.578 GiB (1)
[ 2768437248] 128/ 36535936 sectors allocated at
offset 2.578 GiB (1)
[ 2768502784] 128/ 36535808 sectors allocated at
offset 2.578 GiB (1)
[ 2768568320] 128/ 36535680 sectors allocated at
offset 2.578 GiB (1)
> cp is working well but no qemu-img
Good, so this looks like a QEMU bug.
Try enhancing the error output like this:
diff --git a/qemu-img.c b/qemu-img.c
index 6a39731..c300164 100644
--- a/qemu-img.c
+++ b/qemu-img.c
@@ -1010,8 +1010,9 @@ static int img_convert(int argc, char **argv)
ret = bdrv_read(bs[bs_i], sector_num - bs_offset, buf, n);
if (ret < 0) {
- error_report("error while reading sector %" PRId64 ": %s",
- sector_num - bs_offset, strerror(-ret));
+ error_report("error while reading bs_i %d sector_num %"
+ PRId64 " bs_offset %" PRId64 " n %d: %s",
+ bs_i, sector_num, bs_offset, n, strerror(-ret));
goto out;
}
/* NOTE: at the same time we convert, we do not write zero
Perhaps one of the arguments is out of range. Are you comfortable
applying this patch to qemu-img.c, rebuilding, and running the
qemu-img convert again?
Stefan
