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.