qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] qemu NBD client behaviour when device size is not a mul


From: Eric Blake
Subject: Re: [Qemu-devel] qemu NBD client behaviour when device size is not a multiple of 512
Date: Tue, 31 Jul 2018 13:25:16 -0500
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0

On 07/31/2018 01:00 PM, Richard W.M. Jones wrote:

Hi Eric.  Is this a bug?

   $ nbdkit -fv random size=1023

(You can choose any size which is not a multiple of 512.)

   $ qemu-img convert nbd:localhost:10809 /var/tmp/test
   qemu-img: error while reading sector 0: Invalid argument

Or more directly:

$ qemu-io -r -f raw --trace=nbd_\* nbd://localhost:10809
...
address@hidden:nbd_receive_negotiate_size_flags Size is 1023, export flags 0x3
qemu-io> r -v 0 1023
address@hidden:nbd_send_request Sending request to server: { .from = 0, .len = 1024, .handle = 94749973992480, .flags = 0x0, .type = 0 (read) } address@hidden:nbd_receive_simple_reply Got simple reply: { .error = 22 (EINVAL), handle = 94749973992480 }
read failed: Invalid argument

Yep. Looks likes the client code is trying to enforce 512-byte alignment, and qemu rounds ALL disk sizes up to the next sector boundary (even when the actual disk is unaligned). I'll have to patch things to not round past image end on the final partial sector.

Note that with qemu as server:

$ truncate --size=1023 file
$ qemu-nbd -f raw -x '' file

the client now sees:

address@hidden:nbd_opt_go_info_block_size Block sizes are 0x200, 0x1000, 0x2000000
...
address@hidden: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 SHOULD happen is that if qemu as server advertises a block size, it should truncate the advertised image size DOWN (not round up). I'm also not sure why qemu as server is advertising 512-byte blocks when backed by a file - it should be able to advertise 1-byte blocks. Likewise, qemu as client should pay attention to the size advertised by the server: if it is not sector-aligned and the server did not advertise block size, then assume that byte alignment works; if the server DID advertise block size (greater than 1) then qemu should round the image size down (as obeying the advertised block size implies that the partial sector at the end is inaccessible without violating NBD protocol - although the NBD protocol also states that servers SHOULD advertise a size that is a multiple of the block size).

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.

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



reply via email to

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