[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-block] [PATCH for-4.0?] nbd/client: Deal with unaligned size f
Re: [Qemu-block] [PATCH for-4.0?] nbd/client: Deal with unaligned size from server
Thu, 28 Mar 2019 07:23:33 -0500
Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.0
On 3/28/19 6:40 AM, Kevin Wolf wrote:
>> Note that qemu as the server refuses to send an unaligned size, as it
>> has already rounded the unaligned image up to sector size, and then
>> happily resizes the image on access (at least when serving a POSIX
>> file over NBD). But since third-party servers may decide to kill the
>> connection when we access out of bounds, it's better to just ignore
>> the unaligned tail than it is to risk problems. We can undo this hack
>> later once the block layer quits rounding sizes inappropriately.
>> Reported-by: Richard W.M. Jones <address@hidden>
>> Signed-off-by: Eric Blake <address@hidden>
> I think making the behaviour inconsistent across different block
> drivers, so that some round up and some round down, is a bad idea.
> Even without the inconsistency, rounding down is already a bad idea
> because it means data loss when you copy the disk.
Concur, truncation is safe, but surprising when it is not done
consistently (and we're too late to switch away from our current
behavior of rounding up).
> This leaves two options:
> 1. Leave things as they are, size gets rounded up. With some servers,
> we might get the data we need, but padded with zeros or garbage. This
> should be fine. With other servers, you might get an I/O error and
> the connection might be dropped when you actually access the last
> block. Nasty, but at least it doesn't fail silently, and you can
> still access the rest of the image.
Well, you can only access the rest of the image if qemu doesn't try to
do a read larger than the last sector. 'qemu-img convert' has the nasty
habit of trying to read as much as possible, and then dying on the EIO
caused by the partial last sector even though it COULD have split the
request into the head (which is still readable) and the tail (< 512
bytes), for maximum copying.
> 2. Just return an error in .bdrv_open when the NBD device has an
> unaligned size. No surprising I/O errors or dropped connections later
> on, but you can't access the image at all.
Tempting, but harsh.
Teach the nbd code to special-case past-EOF read and block-status to do
the right thing, but not worry about write/write-zero/trim (those will
fail, but that's less important for qemu-img convert).
I'll post a v2 patch along those lines.
Eric Blake, Principal Software Engineer
Red Hat, Inc. +1-919-301-3226
Virtualization: qemu.org | libvirt.org
Description: OpenPGP digital signature