Subject: stateid question

From: David Robinson <[email-masked]>
Date: Thu, 14 Oct 1999 15:01:28 -0700 (PDT)

>  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

---

From: Neil Brown <[email-masked]>
Date: Fri, 15 Oct 1999 10:22:06 +1000 (EST)

Well, I can see that my proposal for changing the way stateids works
has met with somewhat less that universal approval :-), so I will drop it
for now - at least until I have looked more thoroughly at the
archives.

Two parting points though:

 1/ For the sake of clarity, I think the document should:
  
   - State clearly that there are two different sorts of stateids, one
     for share and record locks, the other for delegations.

   - Make it clear that each "nfs_lockowner" is associated with a
     particular "principal", and that a credential for that principal
     must accompany any request using a stateid that is allocated to
     that "nfs_lockowner".

   - Make both the static and dynamic nature of locking stateids clear.
     I.e. they are "static" in that they always refered to the agreed
       state maintained by the server on behalf of a lockowner for a
       file.
       They are dynamic in that the stateid number changes with every
       change to the state (contrast this to a fileid which DOESN'T
       change with every change to the file)

   None of these were clear to me on the first reading, though they
   are now.

 2/ I did not expect my proposal to similify the implementation of the
    server or the client substantially.  It was, rather, intended to
    simplify the protocol (thus making it easier for humans to grasp).

    The protocol currently has:
		 stateid for locks
		 stateid for delegations
		 seqid to sequence lock requests
		 nfs_lockowner to "own" individual states
		 client to "own" a collection of state.

    There is a lot of overlap here (two owners, two stateids, two
    things that change with every lock request).

    I had hoped to reduce it to:
		 stateid for all opens/locks/delegations
		 client to own a set of state

    To me, this is much simpler.  I am not yet convinced that it is
    impossible, but I am certain that there is atleast a halfway point
    that reduces the number of concepts represented in the protocol
    without reducing functionality of reliability.

Thankyou for the discussion, it has been most helpful.

NeilBrown