Re: [PATCH 4/4] block: introduce BDRV_MAX_LENGTH

[Eric Blake <eblake@redhat.com>]

On 1/7/21 6:20 AM, Richard W.M. Jones wrote:

>> Actually that's not the only problem.  It appears that we're unable to
>> read or write the last sector of this disk:
>>
>> $ nbdkit memory $(( 2**63 - 2**30 )) --run 'build/qemu-io -r -f raw "$uri" -c "r -v $(( 2**63 - 2**30 - 512 )) 512" ' 
>> read failed: Input/output error
>>
>> $ nbdkit memory $(( 2**63 - 2**30 )) --run 'build/qemu-io -f raw "$uri" -c "w -P 3 $(( 2**63 - 2**30 - 512 )) 512" ' 
>> write failed: Input/output error
>>
>> You can play around with the constants.  I found it's possible to read
>> and write the non-aligned 512 bytes starting at 2^63-2^30-513.  Could
>> be a fencepost error somewhere in qemu?
> 
> Actually this is a pre-existing bug in qemu.
> 
> What happens is qemu-io calls qemu_strtosz("9223372035781033472")
> which returns 0x7fffffffc0000000 and no error.  That answer is plain
> flat out wrong.  The reason for that is qemu_strtosz uses floating
> point for the calculation(!) so is limited to 53 bits of precision and
> silently truncates.

I'm working a patch for that soon.  It was easy to fix things to parse
with full 64 bits of precision while still allowing a fractional bump
(for things like 1.5M), but harder to chase down all the spots in the
testsuite that are impacted by our parser now being more accurate.

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