Re: [Qemu-devel] [PATCH for-4.0 v3 0/6] NBD server alignment improvement

[Eric Blake]

On 3/29/19 11:40 AM, Richard W.M. Jones wrote:
> 
> I tested this version of qemu against the nbdkit test suite and it
> passed.
> 
> It also fixes the problem with qemu-img convert:
> 
>   $ ./nbdkit -U - memory size=511 --run 'qemu-img convert $nbd /var/tmp/out'
> 
> There are a couple of issues though (I don't think you'll think they
> are bugs).
> 
> Firstly it rounds up the size to 512 bytes.  eg. /var/tmp/out above is
> 512 bytes, and qemu-img info shows the virtual size as 512 bytes.

Well, that's the long-standing problem that qemu rounds up to sector
boundaries, instead of being byte-accurate. Not going to get fixed for
4.0, but I've got my on it for 4.1.

> 
> Secondly I still can't open the INT64_MAX image which as you will
> recall has a 511 byte tail:
> 
>   $ ./nbdkit -U - memory size=$((2**63 - 1)) --run 'qemu-img info $nbd'
>   qemu-img: Could not open 'nbd:unix:/tmp/nbdkitTimYSJ/socket': Could not 
> read image for determining its format: File too large

Correct, fallout of the point above (rounding up overflows).

> 
> ... yet the 2^63-512 image can be opened (same as before):
> 
>   $ ./nbdkit -U - memory size=$((2**63 - 512)) --run 'qemu-img info $nbd'
>   image: nbd+unix://?socket=/tmp/nbdkitHSAzNz/socket
>   file format: raw
>   virtual size: -8388607T (9223372036854775296 bytes)
>   disk size: unavailable
> 
> I've just noticed that the virtual size negative (also in upstream
> qemu).  That looks like a bug too ...

Yes, it does. I'll see if I can find a quick fix for that formatting
routine.

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

signature.asc
Description: OpenPGP digital signature