Re: Linux & NFS caching: reducing TCO

Charles K Hardin (chardin+@andrew.cmu.edu)
Fri, 14 May 1999 13:38:08 -0400 (EDT)

>
> This is wrong. NFSv2 does allow for client-side caching, and the
> write-gathering implemented on most servers gives a limited form of
> server-side caching. The difference between NFSv2 and NFSv3 is that
> the latter allows you to better control of the server-side caching:
> the client has a way of telling the server that 'I've sent you all the
> data I want you to write, please flush it to disk now'.
>
> There is, however, still nothing in NFSv3 that breaks the idea of
> statelessness.
>
> Cheers,
> Trond

Excerpts from RFC 1094 - Network File System ver 2
All of the procedures in the NFS protocol are assumed to be
synchronous. When a procedure returns to the client, the client can
assume that the operation has completed and any data associated with
the request is now on stable storage. For example, a client WRITE
request may cause the server to update data blocks, filesystem
information blocks (such as indirect blocks), and file attribute
information (size and modify times). When the WRITE returns to the
client, it can assume that the write is safe, even in case of a
server crash, and it can discard the data written. This is a very
important part of the statelessness of the server. If the server
waited to flush data from remote requests, the client would have to
save those requests so that it could resend them in case of a server
crash.

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

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.

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).

-
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/