Re: [Qemu-block] [Qemu-devel] [PATCH v3 1/6] iotests: Add 241 to test NBD on unaligned images

[Eric Blake]

On 3/28/19 11:27 PM, Eric Blake wrote:
> Add a test for the NBD client workaround in the previous patch.  It's
> not really feasible for an iotest to assume a specific tracing engine,
> so we can't really probe trace_nbd_parse_blockstatus_compliance to see
> if the server was fixed vs. whether the client just worked around the
> server (other than by rearranging order between code patches and this
> test). But having a successful exchange sure beats the previous state
> of an error message.
> 
> Not tested yet, but worth adding to this test in future patches: an
> NBD server that can advertise a non-sector-aligned size (such as
> nbdkit) causes qemu as the NBD client to misbehave when it rounds the
> size up and accesses beyond the advertised size. Qemu as NBD server
> never advertises a non-sector-aligned size (since bdrv_getlength()
> currently rounds up to sector boundaries); until qemu can act as such
> a server, testing that flaw will have to rely on external binaries.
> 
> Signed-off-by: Eric Blake <address@hidden>
> ---

> +printf %01000d 0 > "$TEST_IMG_FILE"
> +nbd_server_start_unix_socket -f $IMGFMT "$TEST_IMG_FILE"
> +TEST_IMG="nbd:unix:$nbd_unix_socket"
> +
> +$QEMU_IMG map --output=json "$TEST_IMG" | _filter_qemu_img_map
> +$QEMU_IO -c map "$TEST_IMG"

These need '-f $IMGFMT' added in, otherwise they default to probing, and
probing forcefully sets alignment to 512 (because it's easier to enforce
no bad writes to sector 0 that way).

I'll squash that in.

And actually, it works to my advantage - I've got another patch coming
that can spot the difference between a client with alignment 1 vs.
alignment 512 (as I found out the hard way, when I had to debug why my
patch wasn't working the way I thought it should be).

-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.           +1-919-301-3226
Virtualization:  qemu.org | libvirt.org

signature.asc
Description: OpenPGP digital signature