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

[Richard W.M. Jones]

On Thu, Mar 28, 2019 at 07:23:33AM -0500, Eric Blake wrote:
> 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.

Yes I just noticed this again ...

$ nbdkit -U - -f memory size=513 --run 'qemu-img convert $nbd /var/tmp/out'
nbdkit: memory.2: error: invalid request: NBD_CMD_READ: offset and count are 
out of range: offset=0 count=1024
qemu-img: error while reading sector 0: Invalid argument

Annoying but can be fixed by the blocksize or truncate filters.

Rich.

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




-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
Fedora Windows cross-compiler. Compile Windows programs, test, and
build Windows installers. Over 100 libraries supported.
http://fedoraproject.org/wiki/MinGW