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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature


[Index of Archives]     [Linux Filesystem Development]     [Linux USB Development]     [Linux Media Development]     [Video for Linux]     [Linux NILFS]     [Linux Audio Users]     [Yosemite Info]     [Linux SCSI]

  Powered by Linux