Re: NFSD Regression: client observing a file while other client writes to it leads to stale local cache

["J. Bruce Fields" <bfields@fieldses.org>]

On Tue, Mar 02, 2021 at 02:03:58AM +0100, Timo Rothenpieler wrote:
> 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.

Hm, I wonder if we're (incorrectly) giving out a delegation to the
reading client.  Is this 100% reproduceable?

--b.

> 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.
>