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