On 01.03.2021 19:46, J. Bruce Fields wrote:
> Thanks for the bisecting this and reporting the results.
> 
> The behavior you describe is probably not a bug: NFS close-to-open
> caching semantics don't guarantee you'll see updates on the reading
> client in this case.
> 
> Nevertheless, I don't understand why the behavior changed with that
> commit, and I'd like to.
> 
> The only change in behavior I'd expect would be that the writing client
> would be granted a read delegation.  But I wouldn't expect that to
> change how it writes back data, or how the reading client checks for

The writing side of things does not seem to be affected.
At any point during testing, the file on the servers filesystem is in 
the state I'd expect it to be, growing by one line per second.

What's also a bit odd about this is that after both clients have closed 
the file, the reading client still sees an older version of the file, 
the one state it was in when it was first opened on the client.
The file size in stat()/ls -l mismatches between the reading client and 
the server.
It stays in that state for some seemingly arbitrary amount of time.
Observing the file in any way(cat/tail, or even just ls) appears to 
extend the wait time.
After leaving the file alone for long enough on the reading client, it 
snaps back to reality.


This change in behavior, while clearly an edge case, is quite 
devastating for our use case. And also somewhat counter-intuitive.

It's the log output of cluster jobs sent off to compute nodes by the users.
They then observe what the job is doing via tail -f on the log file on 
the login node.