|
From: | Eric Blake |
Subject: | Re: [Qemu-block] [VDSM] travis tests fail consistently since Apr 14 |
Date: | Mon, 11 Jun 2018 14:59:38 -0500 |
User-agent: | Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 |
On 06/11/2018 11:19 AM, Kevin Wolf wrote:
Opened the following bug: https://bugzilla.redhat.com/1589738Adding qemu-blockIt'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 <address@hidden> 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
[Prev in Thread] | Current Thread | [Next in Thread] |