Subject: [nfsv4] more on server cache algorithm

From: [email-masked]
Date: Tue, 18 Nov 2003 14:28:54 -0500 (EST)

> What do you do if you get a compound with only one non-idempotent op and
> a large number of idempotent ops including operations such as
> read/readlink/readdir which will cause the reply to be very large.
> Saving the reply in this case might take up too much space.

Good point. As of now, the algorithm would save it.
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.
(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
[email-masked]
https://www1.ietf.org/mailman/listinfo/nfsv4

---

From: Eric Werme USG <[email-masked]>
Date: Tue, 18 Nov 2003 15:22:07 -0500

I think I thought of that once upon a time and then realized that COMPOUNDs
that include READs probably wouldn't include anything else.  Besides, the
cached reply could leave out the idempotent parts.  Then the processing
of the retransmitted request would form the reply from cached data and
fill in the holes by reexecuting those parts.  It might not even take
much code.

I could see COMPOUNDs that include CREATE, RENAME, etc. and READDIR....

   Could be fun, rick

Could be fun to write a malicious client that makes subtle changes in
the retransmitted requests too.

	-Ric