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

[Suresh Jayaraman <sjayaraman@suse.de>]

On 10/05/2010 07:57 PM, Jeff Layton wrote:
> On Mon, 20 Sep 2010 14:25:36 -0400
> "J. Bruce Fields" <bfields@fieldses.org> wrote:
> 
>> 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.
>>
> 
> I can sort of see the argument too, but on the other hand...does anyone
> *really* use locks in this way? If we want a mechanism to allow the
> client to force cache invalidation on an inode it seems like we'd be
> better off with an interface for that purpose only (dare I say
> ioctl? :).
> 
> Piggybacking this behavior into the locking interfaces seems like it
> punishes -o nolock performance for the benefit of some questionable
> usage patterns.
> 

+ 1

> Mixing this in with -o local_lock also seems confusing, but if we want

I too think it would be confusing and unwarranted. A separate interface
would be a better choice IMHO..



-- 
Suresh Jayaraman