Messages in this thread | | | Date | Fri, 14 May 1999 20:03:21 +0200 (CEST) | Subject | Re: Linux & NFS caching: reducing TCO | From | Trond Myklebust <> |
| |
>>>>> " " == 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/
| |