On 06/11/2018 11:19 AM, Kevin Wolf wrote:
>> Opened the following bug:
>>
https://bugzilla.redhat.com/1589738
>>
>
> Adding qemu-block
It's related to the unaligned image size. Correct image files should be
aligned to 512 byte sectors, so something is wrong with your image to
start with (hard disks don't have half sectors).
Anyway, git bisects points to this one:
a290f085901b528265787cd27ebda19c970be4ee is the first bad commit
commit a290f085901b528265787cd27ebda19c970be4ee
Author: Eric Blake <eblake(a)redhat.com>
Date: Tue Feb 13 14:26:44 2018 -0600
file-posix: Switch to .bdrv_co_block_status()
Hmm, definitely fallout from my changes.
I think the problem is a bit higher up the call stack, but I'm not
completely sure yet. It manifests in img_map(), in this code:
while (curr.start + curr.length < length) {
...
n = QEMU_ALIGN_DOWN(MIN(1 << 30, length - offset), BDRV_SECTOR_SIZE);
ret = get_block_status(bs, offset, n, &next);
The loop condition is still true because a single byte is left to be
processed, but n is aligned down to 0. I'm not sure why the
QEMU_ALIGN_DOWN() is even there.
Eric, would just removing the QEMU_ALIGN_DOWN() be correct?
I think so, but I'm testing it now. If so, the real culprit was that I
added the rounding in commit 5e344dd8 when I switched qemu-img.c
get_block_status() to take bytes but operate in sectors, but didn't
remove it when I later removed sector-based limitations in commit 237d78f8.
--
Eric Blake, Principal Software Engineer
Red Hat, Inc. +1-919-301-3266
Virtualization:
qemu.org |
libvirt.org