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

[Kevin Wolf]

Am 28.03.2019 um 13:23 hat Eric Blake geschrieben:
> 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.

I honestly think it would be okay. If your image isn't even aligned on
512 bytes, it's probably not a Network Block Device, but just a random
Network File. That's not what the protocol was meant for.

> 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.

This would be similar to what file-posix does for short reads (just adds
zero padding), so it should be reasonable to do the same in NBD. This is
probably the nicest option.

Kevin

signature.asc
Description: PGP signature