Re: [PATCH 01/10] NFSD: interlock the use of NFSD_IO_DIRECT for NFS READ and WRITE

["Chuck Lever" <cel@kernel.org>]

On Tue, Sep 29, 2026, at 10:34 AM, Mike Snitzer wrote:
> Now that NFSD supports NFSD_IO_DIRECT for both READ and WRITE it is
> much safer to avoid needless buffered vs direct contention if/when
> only one of them has been configured to use NFSD_IO_DIRECT.
>
> Mixing direct and buffered I/O to the same file causes needless page
> cache invalidation and writeback, so although io_cache_read and
> io_cache_write remain separate interfaces, writing either one adjusts
> the other so that READ and WRITE are never left on opposite sides of
> the buffered/direct divide:

Jeff and I have been discussing making DIRECT the default for WRITEs and
BUFFERED the default for READs. This patch takes us in the opposite
direction.

Nothing here convinces me that mixing the modes is a bad thing to do.
"Needless page cache invalidation" needs some demonstration, and it
needs to show why the right thing to do is make it impossible to mix
modes rather than explore the issue as one or more bugs that can be
fixed. Or... why not let admins explore this for themselves? Where is
the hazard and why does it need to be forbidden by the admin UI?

Later patches in the series assume DONTCACHE is the fallback for
certain cases. Jeff has measured substantial performance deficits for
that mode, and maybe removing DONTCACHE would be a better direction
to take.

The patch that reports the actual stability of a WRITE was dropped
because it broke something (although I don't remember what). As I
recall, even a direct WRITE needs a subsequent COMMIT. Have you
demonstrated that the client COMMIT is a latency problem or that
the memory that is pinned on the client has a noticeable impact?
We suspect that it might, but every time I've measured, avoiding
COMMIT with NFSD has shown no impact on throughput, which is why
NFSD doesn't already do this optimization.

So even if these patches apply mechanically and benefit your workloads,
it would be helpful if we could step back and understand what you are
trying to achieve and how it should coordinate/align with where Jeff
and I want to see this mechanism go. Can we start with that
conversation?


-- 
Chuck Lever (Come to NFS bake-a-thon! https://nfsv4bat.org)