From: Carl Beame (beame@mail1.eircom.net)
Date: 10/04/99-02:44:44 PM Z
From: Carl Beame <beame@mail1.eircom.net> Subject: RE: COMPOUND and the nfs reply cache Message-Id: <1999Oct04.204535+0100@games> Date: 04 Oct 1999 20:44:44 +0100 On Mon Oct 04 19:44:01 1999, Brent Callaghan wrote: > > There's no requirement in the v4 spec that servers use a > duplicate request cache. Nor is there a requirement in > the v2 or v3 spec. No doubt, they're a good idea to have > and server implementors should be encouraged to use them, > but nowhere does the protocol require any guarantees from > the server that it'll detect retransmitted requests (except > for special cases like the CREATE verifier). > Just a note of commercial reality here... There was an older version of a VMS NFS Server which did NOT have a duplicate request cache for non-idempotent operations and our client with Microsoft Word running over it kept failing. You see Microsoft Word renames like mad and on a typical client network (ie. real dirty), replies were lost on a regular basis and OUR client NFS was crashing Microsoft Word. Imaging us trying to tell our customer that our client NFS was not at fault it was the server ... which was fully compliant to the NFS specification. I propose that a non-idempotent response cache IS a requirement of NFS V4. At the same time we should limit the size of any element in the response cache which contains a non-idempotent COMPOUND request. (maybe to one ethernet packet size). We should also give examples of non-idempotent COMPOUND requests (ie. RENAME, READ/WRITE, DELETE, ...). If we don't do this, each of us could create a NFS V4 compliant server and find that some COMPLIANT client is causing us problems. And as well all know, telling one's customer that the client NFS implementation is at fault, not our server, DOES NOT WORK! - Carl
This archive was generated by hypermail 2.1.2 : 03/04/05-01:47:41 AM Z CST