[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH 4/4] block: introduce BDRV_MAX_LENGTH
From: |
Eric Blake |
Subject: |
Re: [PATCH 4/4] block: introduce BDRV_MAX_LENGTH |
Date: |
Thu, 4 Feb 2021 08:05:13 -0600 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.7.0 |
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
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- Re: [PATCH 4/4] block: introduce BDRV_MAX_LENGTH,
Eric Blake <=