Re: [PATCH RFC] iomap: only return IO error if no data has been transferred

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

 



On Tue, Nov 17, 2020 at 03:17:18PM -0700, Jens Axboe wrote:
> If we've successfully transferred some data in __iomap_dio_rw(),
> don't mark an error for a latter segment in the dio.
> 
> Signed-off-by: Jens Axboe <axboe@xxxxxxxxx>
> 
> ---
> 
> Debugging an issue with io_uring, which uses IOCB_NOWAIT for the
> IO. If we do parts of an IO, then once that completes, we still
> return -EAGAIN if we ran into a problem later on. That seems wrong,
> normal convention would be to return the short IO instead. For the
> -EAGAIN case, io_uring will retry later parts without IOCB_NOWAIT
> and complete it successfully.

So you are getting a write IO that is split across an allocated
extent and a hole, and the second mapping is returning EAGAIN
because allocation would be required? This sort of split extent IO
is fairly common, so I'm not sure that splitting them into two
separate IOs may not be the best approach.

I'd kinda like to avoid have NOWAIT IO return different results to a
non-NOWAIT IO with exactly the same setup contexts i.e. either we
get -EAGAIN or the IO completes as a whole just like a non-NOWAIT IO
would.

So perhaps it would be better to fix the IOMAP_NOWAIT handling in XFS
to return EAGAIN if the mapping found doesn't span the entire range
of the IO. That way we avoid the potential "partial NOWAIT"
behaviour for IOs that span extent boundaries....

Thoughts?

Cheers,

Dave.
-- 
Dave Chinner
david@xxxxxxxxxxxxx



[Index of Archives]     [Linux Ext4 Filesystem]     [Union Filesystem]     [Filesystem Testing]     [Ceph Users]     [Ecryptfs]     [AutoFS]     [Kernel Newbies]     [Share Photos]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux Cachefs]     [Reiser Filesystem]     [Linux RAID]     [Samba]     [Device Mapper]     [CEPH Development]

  Powered by Linux