On 05.03.2021 23:31, J. Bruce Fields wrote:
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.
As long as it doesn't get stuck for extended amounts of time, it being a bit janked is fine.
A close and re-open bringing it back up to date that's all I can ask for.Not sure how "tail -f" operates internally. It does seem to have special handling for remote files/network filesystems though, so it might be doing the right thing already.
But as long as calling "cat" on the file repeatedly works, that's fine.
But that particular regression was my fault, thanks again for bisecting and reporting.
I've been running a 5.10 Kernel with the commit reverted for a the whole week now, and haven't run into any issues so far.
Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature
