Re: [PATCH v10 7/7] NFSD: drop a shared boundary page only once both WRITEs have written it

[Christoph Hellwig <hch@lst.de>]

On Tue, Nov 03, 2026 at 04:17:54PM -0500, Mike Snitzer wrote:
> NFSD splits a misaligned direct-mode WRITE into a direct middle and
> buffered DONTCACHE ends.  Each end covers its first or last unit, the
> smallest folio the mapping allows, only partly, and shares that unit
> with the neighbouring WRITE.
> 
> Issue the buffered ends with IOCB_DONTCACHE_DEFER.  Before writing an
> end, ask filemap_dontcache_edge_completes() whether the neighbouring
> WRITE has written its part of each shared unit.  Once the WRITE, its
> fsync included, is done, complete those units with

Why does the write include an fsync?  Are these STABLE writes, and
if yes, why?

> filemap_dontcache_edge_complete().  A short write completes a unit only
> if it wrote its own part of it.
> 
> With this commit, 32 interleaved writers of 47008-byte records through

Can you explain where this very odd number comes from.  Is that just a
worst case?  Or for some reason actually relevant?

> NFSD DIRECT read 0.0001 to 0.0002 blocks per WRITE, instead of reading
> 0.99 blocks per WRITE.  FILE_SYNC WRITEs no longer wake the DONTCACHE
> writeback kick, where they woke it 23,000 to 65,000 times a run without
> IOCB_DONTCACHE_DEFER.  On a four-server pNFS flexfiles rig, the page
> cache grew by 2.9 GiB during the write phase instead of about 11 GiB.

How does this compare to just not using DONTCACHE at all for unaligned
tails (and maybe heads, if for some reason they I/O you care about
reordered writes).  And how does it compare to that plus manual
sync_file_range calls to micro-manage the I/O?

In general I'm not in favour of so many core hacks for
very nfsd-specific behavior.