On Thu, Mar 04, 2021 at 09:42:28AM -0500, J. Bruce Fields wrote: > On Tue, Mar 02, 2021 at 02:23:05AM +0100, Timo Rothenpieler wrote: > > 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. > > OK, I reproduced this myself and watched the network traffic in > Wireshark. > > The server is *not* giving out a read delegation to the writer (which is > what the commit you bisected to should have allowed). It *is* giving > out a delegation to the reader. Which is a truly awful bug. > Investigating.... Yeah, it's completely failing to provide close-to-open cache consistency there in most cases. Arghh. I have some idea how to fix it, but for now it should just be reverted. I'll post that pending some testing. I've also added a pynfs test for this case (4.1 test DELEG9). We should probably have some more. So, thanks for the report. I'd still be a little cautious about your use--NFS can't give you a lot of guarantees when you've got a file open for read and write simultaneously. The writing client can delay those writes at least until the writing application closes, and the reading isn't necessarily going to revalidate its cache until it the reading application closes and reopens. And weirder behavior is possible: for exapmle when the writer does write back, I don't think there's any guarantee it will write in order, so you could end up temporarily with NULLs in the middle. But that particular regression was my fault, thanks again for bisecting and reporting. --b.
