Am 18.11.2016 um 15:35 hat Eric Blake geschrieben:
> On 11/18/2016 08:19 AM, Olaf Hering wrote:
> > Am 18. November 2016 14:43:18 MEZ, schrieb Eric Blake <eblake@redhat.com>:
> >> 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?

Given that we're already a few weeks into the freeze, I would very much
prefer an isolated patch for xen_disk for 2.8, and then it can be
cleaned up during the 2.9 cycle.

Kevin