Re: fall back from direct to buffered I/O when stable writes are required

[Christoph Hellwig <hch@lst.de>]

On Tue, Nov 04, 2025 at 03:38:24PM -0800, Darrick J. Wong wrote:
> IIRC, a PI disk is supposed to check the supplied CRC against the
> supplied data, and fail the write if there's a discrepancy, right?

Yes.

> In
> that case, an application can't actually corrupt its own data because
> hardware will catch it.

Yes.

> A. We can allow mutant directio to non-PI devices because buggy programs
>    can only screw themselves over.  Not great but we've allowed this
>    forever.
>
> B. We can also allow it to PI devices because those buggy programs will
>    get hit with EIOs immediately.

Well, those "buggy programs" include qemu and probably others.  Which
immediately limits the usefulness of operating with PI.

This also does not help with non-PI checksums - one thing my RFC series
did is to allow storing checksums in non-PI metadata, which is useful
for devices that are too cheap for PI, but still provide metadata.  These
do exist, although are not very wide spread, and this will require an
on-disk flag in XFS, so it's not right there.  But compared to all the
others methods to provide checksums, block metdata is by far the best,
so I'll keep it on the agenda in the hope that such devices become
more prelevant.

> I wonder if that means we really need a way to convey the potential
> damage of a mutant write through the block layer / address space so that
> the filesystem can do the right thing?  IOWs, instead of a single
> stable-pages flag, something along the lines of:

Maybe, I actually suggested this earlier.  But breaking the biggest user
of direct I/O (qemu) by default once we have checksums still feels like a
losing proposition.