From: David Robinson (robinson@jetsun.eng.sun.com)
Date: 10/14/99-05:01:28 PM Z
Date: Thu, 14 Oct 1999 15:01:28 -0700 (PDT) From: David Robinson <robinson@jetsun.eng.sun.com> Message-Id: <199910142201.PAA13694@jetsun.eng.sun.com> Subject: stateid question > 1/ How does the server let the client know that it has revoked > the state for a particular file (e.g. revoked a delegation or just > possibly revoked a lock). > With stateid-per-file, it was clear: > any use of the relevant stateid is replied to with > NFS4ERR_EXPIRED > With single-stateid, this must become: > any use of the relevant stateid together with the relevant > filehandle results in NFS4ERR_EXPIRED This is strong reason against a single-stateid. In the common case, all leases expire at the same time so it is not an issue. However there are cases where just one file needs to have its lock removed, forcing all open files to be revalidated will be costly. > However that means that the server must remember all the > filehandles for which is has revoked state. > Alternatively, the client could assert in each request "I believe > I have state for this filehandle" if that is the case. The server > could then reply EXPIRED if doesn't current have any state for the > filehandle with that client. The server must maintain a bunch of open state anyways, the revocation state is not significant. If you go back thru the archives you will find a proposed example implementation of how to handle the per file and per system state needed. The extra assertion you are proposing is exactly a per file stateid. > 2/ Who "owns" the stateid, in terms of what credentials do you need > to change it (i.e. request a state change from this state)? > Possibly more significantly, who "owns" a seqid in the current > proposal? In designing the locking protocol one of the big issues is authentication of requests. Early attempts has global stateids and sequence-ids but they proved to difficult to authenticate. It will require a per system authentication in order to insure that there is not a denial of service by injecting bogus values. If the key id values are maintained on a per file basis, only those who are authenticated to be able to open the file can change these values. Another reason not to have global stateids. I am not seeing any benefit to having a global stateid, just a long list of problems. Conversely I am not seeing any real problems with what is proposed. -David
This archive was generated by hypermail 2.1.2 : 03/04/05-01:47:44 AM Z CST