qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH] xen_disk: convert discard input to byte ranges


From: Eric Blake
Subject: Re: [Qemu-devel] [PATCH] xen_disk: convert discard input to byte ranges
Date: Fri, 18 Nov 2016 08:35:06 -0600
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0

On 11/18/2016 08:19 AM, Olaf Hering wrote:
> Am 18. November 2016 14:43:18 MEZ, schrieb Eric Blake <address@hidden>:
>> On 11/18/2016 04:24 AM, Olaf Hering wrote:
>>> The guest sends discard requests as u64 sector/count pairs, but the
>>> block layer operates internally with s64/s32 pairs. The conversion
>>> leads to IO errors in the guest, the discard request is not
>> processed.
>>
>> Doesn't the block layer already split discard requests into 2^31 byte
>> chunks?
> 
> How would it do that without valid input?  It was wrong before the sectors to 
> bytes conversion, and now its even worse given that all the world fits into 
> an int.

Then it sounds like the real bug is that the block layer
bdrv_co_pdiscard() is buggy for taking 'int count' instead of 'uint64_t
count'.  Eventually, I think the entire block layer should be fixed to
allow 64-bit count everywhere, and then auto-fragment it back down to 31
bits (or even smaller, like NBD's 32M limit or Linux loopback device 64k
limit) as needed, rather than making all the backends reimplement
fragmentation.

> 
> Remember that there is no API to let the guest know about the limitations of 
> the host. 

Correct. But the goal of the block layer is to hide the quirks, so that
the code handling the guest requests can offload all the common work to
one place.

Kevin, is it too late for 2.8 for patches that change bdrv_co_pdiscard
to take a 64-bit count?  Or would that still be under bug-fix category
because of the xen use case?

-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org

Attachment: signature.asc
Description: OpenPGP digital signature


reply via email to

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