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.
