NFS: the new millennium

I've seen large throughput improvements by increasing rsize from 1 MB to 16 MB with Oracle dNFS client, towards NFS-Ganesha on top of GPFS (ESS). The ESS does 8+2p erasure coding, with 1 MB strip size, so 16 MB IOs is the optional size. I don't think wsize was as important, since it could buffer up and do full block size writes on server side -- but this large rsize was needed to ensure full block (16MB) reads.

I don't think other NFS clients support larger than 1 MB rsize/wsize, which seems unfortunate for this kind of storage backend.

> You hit diminishing returns pretty quickly above 1MB on any storage device I've ever worked on.

I suspect you are correct.
How about a database update that needs to perform lots of random writes before a sync is needed? Any single NFS write must be contiguous, so there must be several. Without the v3 COMMIT, every one of those random writes would need to be committed before the write could return.

Or what about writing lots of small files. The NFS client doesn't need to COMMIT until the writeback timer fires, or memory reclaim wants the cache back, or a sync() is requested. Would it not be more efficient to commit when there are lots of dirty files, rather than once for each file?

But the real point is that EVERY other layer in the storage stack has the two phases: write then sync/flush/commit. Why are you so sure that NFS doesn't benefit from also have the same two phases?