Messages in this thread | | | Date | Thu, 13 May 1999 20:21:00 +0200 | From | Jamie Lokier <> | Subject | Re: Linux & NFS caching: reducing TCO |
| |
Colin Hirsch wrote: > The normal mount parameters for nfs only seem to include > a timeout for attribute caching; using tcpdump to check how long a client > chaches file contents it seemed that that time never exceeds a couple of > seconds. > > Is there any way to let the clients use a "proper" caching (even if just > for ro mounted /usr or so)? This could just make all the difference...
What you're seeing isn't normal. I suspect synchronising the client and server clocks would fix your problem.
I've used Linux NFS client for years and it's done very good cacheing. In the 6 months or so I can confirm it definitely does very nice cacheing, with the default mount options.
(This to Solaris NFS server -- though it should be just as good even to user space Linux server).
It's the attribute cache that should be refreshing every few seconds. Data remains cached as long as the attributes keep agreeing. I.e. forever if it doesn't change.
> In such a case it might be necessary to let the server be able to send > a kind of invalidate message to the clients if something changes (I > thought of keeping data in cache for tens of minutes). This whole > setup obviously relies on only few changes and only makes sense for > e.g. /usr but _not_ /home.
I don't know about NFSv3. But NFSv2 which I've used doesn't have invalidate messages.
If you're going to edit a file (e.g. a mail folder), open() revalidates the cache while close() flushes pending writes. If you do an fcntl() lock as well and the server doesn't have a broken lockd daemon, everything is nicely serialised.
The fine details got tidied up towards the end of the 2.1.x kernels.
-- Jamie
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |