Re: [PATCH RFC] xfs: remap block layer ENODATA read errors to EIO

[Christoph Hellwig <hch@infradead.org>]

On Tue, Aug 19, 2025 at 10:14:01AM -0500, Eric Sandeen wrote:
> Though you and Dave seem to have different visions here,

We've already clashed on a slightly different twist of this a few weeks
ago :)

> I do think that
> for XFS's purposes, a failed IO is -EIO unless we explicitly need something
> different. Anything finer grained or distributed to higher layers sounds
> like a bit of a maintenance and correctness nightmare, to me.

Mostly, but not entirely yes.  In general I/O errors that bubble up
to the file system are just that: I/O errors that are not retryable
at this point, as otherwise the drivers / midlayers would have already
delt with it.

But there are a few exceptions to that:

The one thing we had a discussion about was ENOSPC, which can happen
with some thing provisioning solutions (and apparently redhat cares
about dm-thin there).  For this we do want retry metadata writes
based on that design, and special casing it would be good, because
an escaping ENOSPC would do the entirely wrong thing in all layers
about the buffer cache.

Another one is EAGAIN for non-blocking I/O.  That's mostly a data
path thing, and we can't really deal with it, but if we make full
use of it, it needs to be special cased.

And then EOPNOTSUP if we want to try optional operations that we
can't query ahead of time.  SCSI WRITE_SAME is one of them, but
we fortunately hide that behind block layer helpers.

For file system directly dealing with persistent reservations
BLK_STS_RESV_CONFLICT might be another one, but I hope we don't
get there :)

If the file system ever directly makes use of Command duration
limits, BLK_STS_DURATION_LIMIT might be another one.

As you see very little of that is actually relevant for XFS,
and even less for the buffer cache.