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 <rjo...@redhat.com> > >> Signed-off-by: Eric Blake <ebl...@redhat.com> > > > > 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