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