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 <[email protected]>
>> Signed-off-by: Eric Blake <[email protected]>
> 
> 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.

Option 3:

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

Attachment: signature.asc
Description: OpenPGP digital signature

Reply via email to