[PATCH for-11.0 0/3] linux-aio/io-uring: Resubmit tails of short requests

Hanna Czenczek posted 3 patches 2 weeks, 5 days ago
Patches applied successfully (tree, apply log)
git fetch https://github.com/patchew-project/qemu tags/patchew/20260318153206.171494-1-hreitz@redhat.com
Maintainers: Aarushi Mehta <mehta.aaru20@gmail.com>, Julia Suvorova <jusual@redhat.com>, Stefan Hajnoczi <stefanha@redhat.com>, Stefano Garzarella <sgarzare@redhat.com>, Kevin Wolf <kwolf@redhat.com>, Hanna Reitz <hreitz@redhat.com>
There is a newer version of this series
block/io_uring.c   | 83 ++++++++++++++++++++++-----------------
block/linux-aio.c  | 96 ++++++++++++++++++++++++++++++++++++----------
block/trace-events |  2 +-
3 files changed, 123 insertions(+), 58 deletions(-)
[PATCH for-11.0 0/3] linux-aio/io-uring: Resubmit tails of short requests
Posted by Hanna Czenczek 2 weeks, 5 days ago
Hi,

Short reads and writes can happen.  One way to reproduce them is via
FUSE export, if you force it to limit the request length in the
read/write path (patch in the commit messages of patches 2 and 3), but
specifically short writes apparently can also happen with NFS.

For the file-posix block driver, aio=threads already takes care of them.
aio=native does not, at all, and aio=io_uring only handles short reads,
but not writes.  This series has both aio=native and aio=io_uring handle
both short reads and writes.  zone-append is not touched, as I don’t
believe resubmitting the tail (if a short append can even happen) is
safe.


Hanna Czenczek (3):
  linux-aio: Put all parameters into qemu_laiocb
  linux-aio: Resubmit tails of short reads/writes
  io-uring: Resubmit tails of short writes

 block/io_uring.c   | 83 ++++++++++++++++++++++-----------------
 block/linux-aio.c  | 96 ++++++++++++++++++++++++++++++++++++----------
 block/trace-events |  2 +-
 3 files changed, 123 insertions(+), 58 deletions(-)

-- 
2.53.0


Re: [PATCH for-11.0 0/3] linux-aio/io-uring: Resubmit tails of short requests
Posted by Kevin Wolf 1 week, 6 days ago
Am 18.03.2026 um 16:32 hat Hanna Czenczek geschrieben:
> Hi,
> 
> Short reads and writes can happen.  One way to reproduce them is via
> FUSE export, if you force it to limit the request length in the
> read/write path (patch in the commit messages of patches 2 and 3), but
> specifically short writes apparently can also happen with NFS.
> 
> For the file-posix block driver, aio=threads already takes care of them.
> aio=native does not, at all, and aio=io_uring only handles short reads,
> but not writes.  This series has both aio=native and aio=io_uring handle
> both short reads and writes.  zone-append is not touched, as I don’t
> believe resubmitting the tail (if a short append can even happen) is
> safe.

Originally, I think you had intended to loop in coroutine code. Now it
looks like you decided to resubmit already on the lower level directly
when processing completions. Obviously, both approaches work, but I'm
curious what are the reasons that made you pick this approach after all.

Kevin


Re: [PATCH for-11.0 0/3] linux-aio/io-uring: Resubmit tails of short requests
Posted by Hanna Czenczek 1 week, 6 days ago
On 23.03.26 17:28, Kevin Wolf wrote:
> Am 18.03.2026 um 16:32 hat Hanna Czenczek geschrieben:
>> Hi,
>>
>> Short reads and writes can happen.  One way to reproduce them is via
>> FUSE export, if you force it to limit the request length in the
>> read/write path (patch in the commit messages of patches 2 and 3), but
>> specifically short writes apparently can also happen with NFS.
>>
>> For the file-posix block driver, aio=threads already takes care of them.
>> aio=native does not, at all, and aio=io_uring only handles short reads,
>> but not writes.  This series has both aio=native and aio=io_uring handle
>> both short reads and writes.  zone-append is not touched, as I don’t
>> believe resubmitting the tail (if a short append can even happen) is
>> safe.
> Originally, I think you had intended to loop in coroutine code. Now it
> looks like you decided to resubmit already on the lower level directly
> when processing completions. Obviously, both approaches work, but I'm
> curious what are the reasons that made you pick this approach after all.

io-uring did it this way, so I thought for a series for the freeze 
period, it would be safest to just copy what it does.

Hanna