On Fri, 2009-06-12 at 14:49 -0700, Amit Gud wrote: > Trond Myklebust wrote: > > On Fri, 2009-06-12 at 12:30 -0700, Amit Gud wrote: > >> We definitely want lookup caching turned on, always, including both > >> positive and negative caching. But, we need to see new files, unlinks, > >> and renames much quicker than a second. > > > > Then use the lookupcache option, since that's what it is for. > > > > Sorry, I don't understand. > > Copying from your last mail: > > > Secondly, we have already introduced finer control over the lookup > > caching as of Linux 2.6.28 and newer: > > - if you want to ensure that machine A always see new files and > > links immediately once they have been created, then > > '-olookupcache=positive' should turn off negative dentry > > caching. > > - if you also want to ensure that it immediately sees renames, > > unlinks and such, then '-olookupcache=none' will turn off lookup > > caching altogether. > > How is it possible to _not_ disable any caching (positive or negative > dentries) and still be able to see renames, unlinks and such in << 1s? You could set acdirmin/acdirmax to 0, but that just floods your server with GETATTR calls instead of LOOKUPs. Then again, so will your millisecond acdirmin/acdirmax. Furthermore, you would be adjusting the _attribute_ cache timeout (not just the lookup cache), which comes at a cost to all the other operations that depend on those attributes. IOW: readdir(), permissions checking, stat() calls, ... It boils down to this: I'm extremely reluctant to get into an arms race of adding ever more mount options for increasingly finer-tuned attribute cache timeouts. While such an option may meet _your_ machine room requirements here and now, it becomes tiresome over the years as machines gain power, and people first start lobbying for millisecond timeouts, then microseconds, nanoseconds, pico... in order to catch up. Trond -- 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
