Subject: stateid question

From: David Robinson <[email-masked]>
Date: Wed, 13 Oct 1999 18:37:42 -0700 (PDT)

> Without thinking it through, I suspect that continuing the model of multiple
> nfs_lockowner's per client means that your goal of a single
> stateid per client cannot be achieved, but perhaps I'm wrong. If you
> haven't already entered into a dialog with David Robinson (designer of
> the locking/share protocol), and Dave Noveck (designer of the
> delegation protocol), I suggest you do so. 

Mike did a very good job of putting your question in context.  There
might be a possibility of merging the stateid used for locking with
the stateid used for delegation which may simplify things.  I suspect
Noveck and I need to just sit down and discuss it, but I don't think
it will have a radical impact on the protocol either way.

The nfs_lockowner field is necessary to provide arbitration of granting
of locks. For example, the same owner can resend the same lock request
and can expect to get it granted while a different owner will have
it fail.  Much of this is now subsumed by the stateid as it is
the shorthand agreement between the client and server.  You are
right that the client can do the arbitration, for discussion purposes
I will consider a client and entity that maintains lock state for
one or more applications, one physical node may have multiple clients.
However this requires that the server trusts the client to be correct,
traditionally NFS pushes optimization to the client but leaves correctness
to the server.  The addition of the V3 ACCESS procedure is an example,
the client could decide on file access based on the attributes returned
but for correctness it need to as the server.  The other area is the
traditional lock test functionality, the server needs to be able to
return to another client some "name" of who owns the file. Not critical
but highly desired.

	-David

---

From: Neil Brown <[email-masked]>
Date: Thu, 14 Oct 1999 13:08:41 +1000 (EST)

> it will have a radical impact on the protocol either way.

I'm not yet convinced myself that it will make the protocol much
simpler (or will even work) but the idea of "one client/one state" is
very elegant and seems to work, and I think it is worth pursuing (if
only to understand the current proposal better).

> return to another client some "name" of who owns the file. Not critical

1/ But why *would* a client resend the same lock request?  It must
   remember that it already has the lock, so it wouldn't (or needn't) do it
   intentionally, and seqid, or changing stateid protects against RPC
   level resends.
2/ The server has to trust the client to some extent.  Specifically it
   must trust it to manage it's own substructure.
    e.g. Client might manage two processes, A and B.  A has credential
      for X which has write access to /a/file.  B has credential Y
      which doesn't have that access.
    The server must trust the client not to use credential X (which it
    got from A) to authorise B's write requests to /a/file.  Actually,
    the principle running process B is the one doing the trusting.

    In exactly the same way, the server must trust the client to not
    use a lock for process A that has been allocated for process B.

    It is still the server's place to make sure that Client P doesn't
    write to a file where Client Q has a mandatory lock, or a
    deny-write share, but that has nothing to do with the substructure
    of the clients.

3/ I accept that it might be useful to have some idea who has a lock
   when a test shows that there is a lock.  But does the "who" need to
   involve some component of the NFS client?  Is it not enough just to
   know which NFS client has the lock?  
   The only senario that I can imagine where you want to know "who"
   has a lock is if you are a sysadmin chasing down bugs (and I've
   been there). In that case, you ask the server which client has the
   lock, and what the filehandle will look like, and then ask that
   client which process (or thread or whatever is meaningful on the
   client) has locks on that filehandle.

BTW, I understand that an NFSv4 client is a very separated concept
from an NFSv2 client - It is the entity which made a particular
SETCLIENTID call and has the authority to use resources allocated to
that CLIENTID.  However given that both you and Mike thought it
necessary to clarify that, it could be that the word "client" is a
poor choice.  Unfortunately nothing better springs to mind. "agent"
is the best I could come up with.

Thanks for your response.

NeilBrown