On Wed, 17 Nov 2010 13:43:52 -0600 Steve French <smfrench@xxxxxxxxx> wrote: > On Wed, Nov 17, 2010 at 1:40 PM, Steve French <smfrench@xxxxxxxxx> wrote: > > On Wed, Nov 17, 2010 at 1:16 PM, Suresh Jayaraman <sjayaraman@xxxxxxx> wrote: > >> On 11/18/2010 12:09 AM, Jeff Layton wrote: > >>> On Wed, 17 Nov 2010 23:53:34 +0530 > >>> Suresh Jayaraman <sjayaraman@xxxxxxx> wrote: > >>> > >>>> Currently, the attribute cache timeout for CIFS is hardcoded to 1 second. This > >>>> means that the client might have to issue a QPATHINFO/QFILEINFO call every 1 > >>>> second to verify if something has changes, which seems too expensive. On the > >>>> other hand, if the timeout is hardcoded to a higher value, workloads that > >>>> expect strict cache coherency might see unexpected results. > >>>> > >>>> Making attribute cache timeout as a tunable will allow us to make a tradeoff > >>>> between performance and cache metadata correctness depending on the > >>>> application/workload needs. > >>>> > >>>> Add 'actimeo' tunable that can be used to tune the attribute cache timeout. > >>>> The default timeout is set to 1 second. > >>>> > >>>> Also, display actimeo option value in /proc/mounts. > >>> You actually do need to impose a limit here. I suggest looking > >>> very closely at time_before/time_after macros. It'll also be > >>> easier to deal storing actimeo in terms of jiffies instead of > >>> seconds. > >> > >>> Finally, this value needs to be displayed in /proc/mounts. > >>> > >> > >> Did you mean displaying values in jiffies in /proc/mounts? Wouldn't it > >> be confusing for users to see such a higher numbers (usually) when they > >> had used a simple 2 digit number for e.g. during mount? > > > > That is a good question - seems like we ought to allow setting more granular > > timeouts (ie jiffies) but nfs actimeo assumes the value is in seconds > > by default. > > I am fine with allowing actimeo to be specified more than one way (seconds vs > > milliseconds or seconds vs. jiffies) with suffix or prefix or keyword variant. > > This assumes there are apps that might someday need stricter > guarantees (sub 1 second - e.g. 15 per second) but not disable metadata caching. > If we don't think that would ever happen - then I am fine with seconds > everywhere > (actimeo only in seconds, /proc display only in seconds). > I don't see any real need for that level of granularity. 1s should be enough for anyone. :) -- Jeff Layton <jlayton@xxxxxxxxxx> -- To unsubscribe from this list: send the line "unsubscribe linux-cifs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
