I wrote: [stuff snipped]
For the pNFS case, when I implemented a pNFS server for FreeBSD, I assumed that the Metadata server only needed to return a correct size for a file to a client doing a Getattr with a read/write layout after it did a LayoutCommit. This implementation worked ok for the FreeBSD client, but did not work correctly for the Linux-4.17-rc2 kernel. To fix the server implementation to interoperate with the above Linux kernel, I had to add a tunable that makes the server get an up to date size for the Getattr operation for a client when a read/write layout is issued to the client. Just to be clear, I am referring to the case where the Getattr was done by the client that holds the read/write layout and not another client. (This does result in additional overheads whenever a client holds a read/write layout for the file.) I can't remember exactly how the Linux client failed, but I suspect it would see a premature EOF when the size returned by the MDS was smaller than the actual size of the file on the DS.
I honestly don't know if this is a bug in the Linux client or a misinterpretation of RFC5661? A little more info on this.
If I recall correctly, the Linux client only did LayoutCommits after Commits. As such, no LayoutCommit were done after writes to a DS that were FILE_SYNC (or stable, if you prefer). Without the LayoutCommit, the pNFS server didn't know when it needed to get an up to date size. The FreeBSD client does a LayoutCommit after writing to a DS whenever it is done writing, such as an fsync() or close() syscall on the file or an unlock of a write lock on the file. rick