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.