qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH for-4.0?] nbd/client: Deal with unaligned size f


From: Kevin Wolf
Subject: Re: [Qemu-devel] [PATCH for-4.0?] nbd/client: Deal with unaligned size from server
Date: Thu, 28 Mar 2019 12:40:21 +0100
User-agent: Mutt/1.11.3 (2019-02-01)

Am 28.03.2019 um 03:02 hat Eric Blake geschrieben:
> When a server advertises an unaligned size but no block sizes, the
> code was rounding up to a sector-aligned size (a known limitation of
> bdrv_getlength(); maybe 4.1 will fix it to be byte-accurate), then
> assuming a request_alignment of 512 (the recommendation of the NBD
> spec for maximum portability).  However, this means that qemu will
> actually attempt to access the padding bytes of the trailing partial
> sector, without realizing that it is risky.
> 
> An easy demonstration, using nbdkit as the server:
> $ nbdkit -fv random size=1023
> $ qemu-io -r -f raw -c 'r -v 0 1023' nbd://localhost:10809
> read failed: Invalid argument
> 
> because the client rounded the request up to 1024 bytes, which nbdkit
> then rejected as beyond the advertised size of 1023.
> 
> 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.

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.

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.

Kevin



reply via email to

[Prev in Thread] Current Thread [Next in Thread]