qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH v3 6.5/6] nbd/client: Trace server noncompliance


From: Eric Blake
Subject: Re: [Qemu-devel] [PATCH v3 6.5/6] nbd/client: Trace server noncompliance on structured reads
Date: Mon, 1 Apr 2019 15:35:44 -0500
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.0

On 3/30/19 11:53 AM, Eric Blake wrote:
> Just as we recently added a trace for a server sending block status
> that doesn't match the server's advertised minimum block alignment,
> let's do the same for read chunks.  But since qemu 3.1 is such a
> server (because it advertised 512-byte alignment, but when serving a
> file that ends in data but is not sector-aligned, NBD_CMD_READ would
> detect a mid-sector change between data and hole at EOF and the
> resulting read chunks are unaligned), we don't want to change our
> behavior of otherwise tolerating unaligned reads.
> 
> Note that even though we fixed the server for 4.0 to advertise an
> actual block alignment (which gets rid of the unaligned reads at EOF
> for posix files), we can still trigger it via other means:
> 
> $ qemu-nbd --image-opts 
> driver=blkdebug,align=512,image.driver=file,image.filename=/path/to/non-aligned-file
> 
> Arguably, that is a bug in the blkdebug block status function, for
> leaking a block status that is not aligned. It may also be possible to
> observe issues with a backing layer with smaller alignment than the
> active layer, although so far I have been unable to write a reliable
> iotest for that scenario.

More details on why I can't write an iotest (yet) - I wanted to use
blkdebug to let me expose an active image with a required alignment
greater than that of a backing image, but sadly, the current
implementation of blkdebug (and filters in general) reports block status
ONLY for the active layer (it does not properly follow the backing
chain, without Max's patches):

https://lists.gnu.org/archive/html/qemu-devel/2019-04/msg00221.html

But I _finally_ found a way around the fact that blkdebug doesn't (yet)
do what I want - the qcow2 driver has a way to force alignment of 512,
by using encryption.  Thus, with this patch applied, I was able to set
up a scenario that proves our server is still non-compliant (and I hope
to have my patch for fixing it polished enough to send, soon, now that I
can actually test my patch without one-off hacks to manually force the
server into a fixed-size advertisement).

$ printf %01000d 0 > base
$ qemu-img create -f qcow2 -b base -F raw \
  --object=secret,id=s0,data=12345 \
  -o encrypt.format=luks,encrypt.key-secret=s0,encrypt.iter-time=10 \
  top.qcow2 16k
$ qemu-nbd --object secret,id=s0,data=12345 \
 --image-opts driver=qcow2,file.filename=top.qcow2,encrypt.key-secret=s0

$ # in second terminal
$ qemu-io --trace=nbd_\* -f raw nbd://localhost:10809 -c 'r 0 2k'
...
address@hidden:nbd_send_request Sending request to server: {
.from = 0, .len = 2048, .handle = 93824995142096, .flags = 0x0, .type =
0 (read) }
address@hidden:nbd_receive_structured_reply_chunk Got
structured reply chunk: { flags = 0x0, type = 1 (data), handle =
93824995142096, length = 1008 }
address@hidden:nbd_structured_read_compliance server sent
non-compliant unaligned read data chunk
address@hidden:nbd_receive_structured_reply_chunk Got
structured reply chunk: { flags = 0x1, type = 2 (hole), handle =
93824995142096, length = 12 }
address@hidden:nbd_structured_read_compliance server sent
non-compliant unaligned read hole chunk

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

Attachment: signature.asc
Description: OpenPGP digital signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]