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
