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 <ebl...@redhat.com> > ---
> +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