Re: [nfsv4] more on server cache algorithm

["Talpey, Thomas" <[e-mail]>]

At 02:28 PM 11/18/2003, [e-mail] wrote:
>It might be possible to create a scale that indicates
>"how dangerous" redoing the various non-idempotent Ops are and calculate
>a "total risk" (based on how many and which non-idempotent Ops are in the
>RPC). Then use that vs "size of reply" to decide whether or not to save it.

While this may be doable, I think it's important to ask if it's useful. The
global-LRU behavior of server caches really adds very little correctness
to the protocol (apologies to Chet Juszczak), because the "window of
correctness" is actually quite small on a busy server. Even smaller when
you consider that a disconnected client probably takes a while to get a
chance to reconnect. And it doesn't cover the case of server failure, where
the cache is usually lost altogether.

All this is addressed as the core of the sessions proposal that Spencer and
I published in May (draft-talpey-nfsv4-rdma-sess-00.txt). The session id is
assigned to a client persistently, until the client revokes it. And the number
of outstanding requests is bounded, so the server can accurately cache the
replies for the session. I envision the server caching them "forever", at least
until some cron job comes and cleans them out every week or so.

This kind of guarantee is really what's needed to really nail the fundamental
requirement here - correctness in the face of client failure, server failure, and
network partitioning. But the framework you describe is a good one as an
enabler for the cache implementation.

Tom.


>(Trouble is, as soon as you decide to not save some non-idempotent replies,
> the cache almost doesn't seem worth the bother. In fact, the V2,3 BSD
> server that has been out there for several years doing NFS over TCP, never
> cached anything for TCP.)
>
>One thing that might get added to the algorithm when I code it is some sort of
>high water mark on "reply bytes saved" that would allow the amount of storage
>used to be tuned, at the expense of a less effective cache.
>
>In general, I see a lot of places where an NFSv4 server can get very memory
>hungry and I am anxious to see how mine works under heavy load. (This summer,
>I am hoping to rig up one of my teaching labs (40-60 machines) with a v4 client
>so I can load test my server. My challenge at the moment is finding a mature
>client I can use for this. If I succeed, others would be welcome to come
>and do testing on it, as well, if they are interested.)
>
>Could be fun, rick
>
>_______________________________________________
>nfsv4 mailing list
>[e-mail]
>https://www1.ietf.org/mailman/listinfo/nfsv4