Re: Should we be aggressively invalidating cache when using -onolock?

["J. Bruce Fields" <bfields@fieldses.org>]

On Mon, Sep 20, 2010 at 10:41:59AM -0400, Chuck Lever wrote:
> At one point long ago, I had asked Trond if we could get rid of the
> cache-invalidation-on-lock behavior if "-onolock" was in effect.  He
> said at the time that this would eliminate the only recourse
> applications have for invalidating the data cache in case it was
> stale, and NACK'd the request.

Argh.  I guess I can see the argument, though.

> I suggested introducing a new mount option called "llock" that would
> be semantically the same as "llock" on other operating systems, to do
> this.  It never went anywhere.
> 
> We now seem to have a fresh opportunity to address this issue with the
> recent addition of "local_lock".  Can we augment this option or add
> another which allows better control of caching behavior during a file
> lock?

I wouldn't stand in the way, but it does start to sound like a rather
confusing array of choices.

--b.

> 
> It also seems to me that if RHEL 4 is _not_ invalidating on lock, then
> it is not working as designed.  AFAIK the Linux NFS client has always
> invalidated a file's data cache on lock.  Did I misread something?