----- "Jeff Layton" <jlayton@xxxxxxxxxx> wrote: > On Mon, 20 Sep 2010 14:25:36 -0400 > "J. Bruce Fields" <bfields@xxxxxxxxxxxx> 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. > > Mixing this in with -o local_lock also seems confusing, but if we > want > to do that it's probably best to make that call before any kernels > ship > with -o local_lock. > > Trond, care to weigh in on this? Trond, What do you think about this issue? Sachin Prabhu -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
