On 07/31/2018 01:25 PM, Eric Blake wrote:
On 07/31/2018 01:00 PM, Richard W.M. Jones wrote:
Hi Eric. Is this a bug?
Note that with qemu as server:
$ truncate --size=1023 file
$ qemu-nbd -f raw -x '' file
the client now sees:
423068@1533060754.229106:nbd_opt_go_info_block_size Block sizes are
0x200, 0x1000, 0x2000000
...
423068@1533060754.229156:nbd_receive_negotiate_size_flags Size is 1024,
export flags 0x1ed
where qemu as server is 0-padding the source file in all read requests;
and that probably explains why I haven't noticed the problem with
unaligned images in the client before (since qemu as NBD server doesn't
advertise unaligned images). What's more, a write request to the tail
of the partial sector (when not using a read-only connection) succeeds,
and resizes the file in the process (at least, on protocols that support
live resizing); but I wouldn't count on it behaving sanely for all
protocols.
What's more, with qemu as server, then 'qemu-img map' as client dies
because the server is sending incorrect data according to protocol.
At any rate, you've given me plenty to work with for fixing things,
although it probably won't make it into 3.0-rc3 and I don't know if
we'll have an -rc4.
Not a regression introduce in 3.0 (it exists in 2.12), so not serious
enough of a show-stopper to cause an -rc4 release.
--
Eric Blake, Principal Software Engineer
Red Hat, Inc. +1-919-301-3266
Virtualization: qemu.org | libvirt.org
