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

[bfields@fieldses.org (J. Bruce Fields)]

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
file changes.  (The reading client still shouldn't be granted a
delegation.)

I'll take a look.

--b.

On Sun, Feb 28, 2021 at 11:27:53PM +0100, Timo Rothenpieler wrote:
> I've been observing an issue where an NFS client reading(tail -f to
> be precise) a file to which another NFS client is writing(or rather,
> appending. It's a log file of a cluster job), the reading client
> gets stuck, and does not update its view of the file anymore.
> 
> On the server, the file still gets new lines of log added as expected.
> On the reading client, the file gets stuck in the state of the
> moment it's being read.
> And stays that way until the writing site closes it, and some time
> passes after that.
> 
> So, with the NFS Server being on 5.4, the issue did not appear.
> On 5.10, it does. So I bisected the server it with the following setup:
> 
> One Client opening and appending to a file:
> 
> > ( for i in $(seq 1 60); do date; sleep 1; done ) > testfile
> 
> The other just does "fail -f" on the selfsame file.
> 
> On the good side of the bisect, the file updates as expected, and
> tail -f shows new lines as they are added. On the bad side, it just
> gets stuck and never updates. The file size in "ls -l" also gets
> stuck.
> 
> At the end of that bisect, git pointed me at commit
> 94415b06eb8aed13481646026dc995f04a3a534a.
> 
> > nfsd4: a client's own opens needn't prevent delegations
> 
> And indeed, reverting that commit on top of a current 5.10 kernel
> makes the issue go away.
>