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? -- 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
