On 02.03.2021 02:06, J. Bruce Fields wrote:
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 forThe 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?
Server and reading client disagreeing about the files size and contents is 100% reproducible, even after the writing client has long and definitely closed the file.
I'm not 100% certain about the exact timing and extension of timing, since I never did any intensive testing on that. But it stays mismatched between client and server like that for at least several minutes.
Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature
