On 3/28/19 11:27 PM, Eric Blake wrote: > Both NBD_CMD_BLOCK_STATUS and structured NBD_CMD_READ will split their > reply according to bdrv_block_status() boundaries. If the block device > has a request_alignment smaller than 512, but we advertise a block > alignment of 512 to the client, then this can result in the server > reply violating client expectations by reporting a smaller region of > the export than what the client is permitted to address (although this > is less of an issue for qemu 4.0 clients, given recent client patches > to overlook our non-compliance at EOF). Since it's always better to > be strict in what we send, it is worth advertising the actual minimum > block limit rather than blindly rounding it up to 512. >
> Note that the iotests output changes - both pre- and post-patch, the > server is reporting a mid-sector hole; but pre-patch, the client was > then rounding that up to a sector boundary as a workaround, while > post-patch the client doesn't have to round because it sees the > server's smaller advertised block size. > > Signed-off-by: Eric Blake <ebl...@redhat.com> > Reviewed-by: Vladimir Sementsov-Ogievskiy <vsement...@virtuozzo.com> > --- > nbd/server.c | 13 ++++++++----- > tests/qemu-iotests/241.out | 3 ++- > 2 files changed, 10 insertions(+), 6 deletions(-) I missed some iotest changes; 223 and 233 also need patches along the lines of: @@ -41,7 +41,7 @@ export: 'n' size: 4194304 flags: 0x4ef ( readonly flush fua trim zeroes df cache ) - min block: 512 + min block: 1 -- Eric Blake, Principal Software Engineer Red Hat, Inc. +1-919-301-3226 Virtualization: qemu.org | libvirt.org
signature.asc
Description: OpenPGP digital signature
