Trond Myklebust wrote:
> On Thu, 2007-03-08 at 10:03 +1100, Neil Brown wrote:
>>> You can argue for or against the need to invalidate caches when the user
>>> has specified "nolock" (it might be nice to add a Solaris-style "llock"
>>> alias to this one day, btw: nolock == local locking != no locking at
>>> all). We used to do this in early 2.4.x kernels, but that was changed.
>>> The reason is that locking is the only way of ensuring that the NFS
>>> cache is in sync with the server, and the "nolock" exception was
>>> breaking this.

Why not create a special fcntl for NFS files that invalidates cached 
data for that file?  That way, no matter what semantics a lock or unlock 
operation has, there is always a well-defined way to flush the page cache.

>> Yes, the name "nolock" does seem to have been unfortunate.  We had one
>> customer wondering why it wasn't producing an 'ENOLCK' error status.
>> We could create an alias.  "nonlm"?
> 
> I'd prefer "llock", simply because that mirrors the same option on
> Solaris.
> 
>> If you have chosen nocto,nolock, I cannot see any justification in
>> expecting any way of ensuring  the NFS cache is in sync with the
>> server except at unmount.
>>
>> However if you don't like it, that's fine.  It was just a "this might
>> be useful, what do you think" rather than "this is important".  The
>> other patch of the two was the real bugfix.  Did that pass muster?
>>
>> But I worry about adding an 'llock' option that was different from
>> 'nolock'.  How would you explain the difference in a way that didn't
>> confuse people?
> 
> Are we sure that 'llock' differs from 'nolock'? If Chuck is right, then
> we could simply make 'llock' set both the 'nolock' 'nocto' flags, and
> just document that. I'm not sure that he is, though. According to the
> manpage, Solaris documents
> 
>         nocto
>         
>                 No close-to-open consistency.
>         
>         llock
>         
>                 Local locking being used (no lock manager).

We should be careful here.  Solaris, IIRC, has different cache coherency 
semantics from Linux when a file is locked, so it might be difficult to 
compare mount options directly between Linux and Solaris.

Locked NFS files on Solaris get uncached I/O limited to 8KB.  I don't 
know exactly how llock changes this, but I suspect it probably doesn't 
change it at all.  Perhaps someone with Solaris NFS development 
experience can shed some light.

IMO an llock mount option is sorely missing on Linux... and I think it 
should disable the "automatic" cache flushing behaviors as well.  When 
local locking is used, clearly cache coherency with other clients isn't 
needed, and therefore invalidate-on-lock and flush-on-unlock semantics 
are not necessary and serve only to slow things down.

I don't necessarily disagree with Trond about requiring some mechanism 
for cache invalidation to be available.  However, as an aside, if the 
NFS cache invalidation logic is working overall, it really shouldn't 
ever be necessary for applications to trigger invalidation by hand.