Subject: RE: changes to nfs4_prot.x / protocol description

From: "Noveck, Dave" <[email-masked]>
Date: Wed, 10 Oct 2001 11:37:07 -0700

> > > (2) Consider this scenario with three lockowners L1, L2, L3.
> > > Initially L1 has a file open with (open) stateid A, and L2 has
> > > the same file open with (open) stateid B.  The new LOCK operation
> > > is used to derive lock stateid C, for lockowner L3, from open
> > > stateid A.  The client then attempts to use the LOCK operation
> > > again to derive a new lock stateid, for lockowner L3, from open
> > > stateid B.  Does this:
> > >   (a) succeed, and instantiate new lock stateid D, which will
> > >       be independent from lock stateid C,
> > >   (b) succeed, but not instantiate a new lock stateid (the
> > >       server would return an updated version of stateid C), or
> > >   (c) fail with an error?
> >
> > (a) is the right answer.  So in the case of a Posix client that is
> > able to open() a file more than once and then do file locking on those
> > separate file descriptors and not have the lock conflict, the client
> > needs to use the same open_owner for all opens of the same file.  This
> > way the lockowner will be assigned appropriately.

> I don't understand what this means.  It sounds like you are saying that,
> in scenario (a) described above, locks placed using the new lock stateid D
> would conflict with locks placed using the old lock stateid C (even though
> the associated lockowner is the same in both cases).  In other words, the
> lock stateid is the unit of lock contention (I had assumed it would be the
> lockowner).  Is this correct, or would locks set using lock stateid C be
> indistinguishable from locks placed using lock stateid D?

I understood Spencer to be saying that locks for stateid C and stateid D would
not conflict and that the lockowner is the unit of lock contention.

But I still don't understand how this argues for (a).  I think (c) is the
correct answer.  In your example L3 took (open) stateid B and got (lock)
stateid C.  I would argue that if that lock owner wants to get another lock,
the appropriate thing to do would be pass stateid C in the LOCK request
and get back stateid D, at which point further use of stateid C would
not be valid (it would result in OLD_STATEID).  A different lockowner (L4 
say) could validly use B and get his own lock stateid but I don't see
that we should allow a single lockowner to take a single open stateid
and split into multiple lock-stateid sequences.

---

From: "Kendrick M. Smith" <[email-masked]>
Date: Mon, 15 Oct 2001 15:29:57 -0400 (EDT)

> > > >       server would return an updated version of stateid C), or

So far, we have one vote for (a) and one for (c).  Personally, my vote is
for (c).  Any other takers?  Can we reach consensus on this question?

Here is another question for the list: Suppose that a client has finished
using a lock_stateid, but wants to keep the associated open_stateid.  Is
it legal for the client to send a CLOSE for the lock_stateid?  Under my
interpretation of the new .x, the answer would be "no" since the argument
to the new CLOSE is listed as an open_stateid.  Assuming that the answer
is "no", is there any way for the server to know when the lock_stateid can
be reaped?  (I don't see any.)  I find this situation somewhat worrisome
because it means that a client can inadventantly create unbounded state on
the server.  This could happen e.g. if a process keeps a file open for an
extended period of time, then forks a bunch of children which each lock
the file.  While this is unlikely, it doesn't seem totally farfetched
either: a server which forks a new process to deal with each incoming tcp
connection might conceivably do this.

- k