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

From: "Noveck, Dave" <[email-masked]>
Date: Mon, 15 Oct 2001 12:46:36 -0700

In your example, server state for the stateids created by each
child and for each lock_owner can't be reaped until the CLOSE
of the original open, which mught not happen for a very long
time.

I think if CLOSE is not allowed on a lock stateid, I thnk we
are going to need some other way to allow the server to release 
these resourcse.

-----Original Message-----
From: Kendrick M. Smith [mailto:[email-masked]]
Sent: Monday, October 15, 2001 3:30 PM
To: Noveck, Dave
Cc: Spencer Shepler; [email-masked]
Subject: RE: changes to nfs4_prot.x / protocol description

> > > > (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?

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

---

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

> are going to need some other way to allow the server to release

I think that the easiest solution is to allow CLOSE on a lock stateid.
How about changing the 'open_stateid' field in CLOSE4args to a field
of type closer4, defined by:

union closer4 switch (bool is_open_stateid) {
 case TRUE:
	stateid4		open_stateid;
 case FALSE:
	stateid4		lock_stateid;
}

I'm not proposing that we try to fit this change, or any other such
change, in before the bakeoff.

- k