lkml.org 
[lkml]   [1999]   [May]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
SubjectRe: Linux & NFS caching: reducing TCO
From
>>>>> " " == Charles K Hardin <chardin+@andrew.cmu.edu> writes:


> In no uncertain terms does NFSv2 Spec allow server-side
> caching, just because implementations do this - does not make
> it conform to a spec.

It does: look at how it's implemented. If a new request arrives before
the server has committed to disk, and acknowledged, then the latter is
committed together with the preceding request. In no way does this
break RFC 1094.

> The client-side caching is fuzzy because the RFC does not
> explicitly disallow it. The common rule for consistency issues
> is no caching since there are no callbacks in NFS (ie, no way
> to invalidate a cached file on the client). This is the price
> you pay for stateless servers in that callbacks add state.

> Once again, NFS implementation will do client side caching for
> performance. This will break strong consistency semantics
> though (without some bad hack to get a choerence protocol
> running between the clients).

> The whole fsync hack to "maintain consistency" on NFS servers
> is interesting at best, but I wouldn't maintain bank records on
> it.

Then Linux-2.2 is not something for you...

> NFSv3 is interesting in that it acknowledges that client-side
> caching is not specified but it tries to give some additional
> hints to help the client manage their cache (ie, returing the
> attributes of a command that affected those attributes to avoid
> a GETATTR).

This is also part of NFSv2 for most commands: look up READ, WRITE,
LOOKUP, CREATE, MKDIR, and most other commands. As for NFSv3, the main
interest is that of speed and 64-bit filesizes; not security. Weak
cache consistency idea gives you very little new information since you
generally have no guarantee that your sunrpc requests are ordered when
using UDP. Please see the NFSv3 patches for how we currently use that
information...

Cheers,
Trond

-
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.204 / U:0.284 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site