lkml.org 
[lkml]   [1999]   [May]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 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/

\
 
 \ /
  Last update: 2005-03-22 13:51    [W:0.020 / U:3.616 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site