Re: [PATCH v2 1/1] iomap: propagate nowait to block layer

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

 



On Wed, Mar 05, 2025 at 12:45:52AM +0000, Pavel Begunkov wrote:
> It's not something recent. After some digging I think the
> one I remember is
> 
> https://lore.kernel.org/all/20190717150445.1131-2-axboe@xxxxxxxxx/
> 
> Remove by
> 
> commit 7b6620d7db566a46f49b4b9deab9fa061fd4b59b
> Author: Jens Axboe <axboe@xxxxxxxxx>
> Date:   Thu Aug 15 11:09:16 2019 -0600
> 
>     block: remove REQ_NOWAIT_INLINE

That does indeed look pretty broken, mostly because it doesn't actually
return the errors inline as return values but tries to emulate it.

> > If you don't want to do synchronous wouldblock errors that's your
> > only option.  I think it would suck badly, but it's certainly easier
> > to backport.
> 
> Is there some intrinsic difference of iomap from the block file
> in block/fops.c? Or is that one broken?

block/fops.c has roughly the same issue, but it's not anywhere near
as sever, as block/fops.c doesn't have any file system state that
gets confused by the async BLK_STS_AGAIN.  But unless io_uring knows
how to rewind the state for that case it probably also doesn't work
properly.  It might be worth to look into testcases that actually
exercise the nowait I/O on block devices with annoyingly small limits
or that split a lot (like RAID0).





[Index of Archives]     [XFS Filesystem Development (older mail)]     [Linux Filesystem Development]     [Linux Audio Users]     [Yosemite Trails]     [Linux Kernel]     [Linux RAID]     [Linux SCSI]


  Powered by Linux