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

From: "Noveck, Dave" <[email-masked]>
Date: Fri, 5 Oct 2001 12:10:55 -0700

I think I was the one who originally proposed this
and it was to deal with a specific problem in one of
the proposals that Spencer made to deal the fork 
problem.  I had been assuming that this issue still
applied to Spencer's current approach, but I haven't
verified that.

The issue applied if the scope within which open
stateids were resolved (i.e. the universe of current
OPEN such that for a given file all such open merged
and thus for which a single CLOSE would be appropriate),
was larger that the scope of requests subject to a 
single seqid (the old-fashioned seid) sequence.  In
such an environment, two OPEN's for the same file
or that after the fact turn out to be for the same 
file (don't you just love hard links?) could be 
performed in parallel and with purely opaque stateids
there would be no way for the client to determine which
one was generated later and thus has priority.

I haven't yet tried to put the new nfs_prot.x together with
Spencer's last mail message on this revision of the 
locking/open model yet, so that I can really say that I
understand how all this will work, but that's the background, 
as far as I understand it.

-----Original Message-----
From: Kendrick M. Smith [mailto:[email-masked]]
Sent: Friday, October 05, 2001 2:51 PM
To: [email-masked]
Subject: RE: changes to nfs4_prot.x / protocol description

According to the update, stateid4's are now defined as:

struct stateid4 {
	uint32_t	seqid;
	opaque		other[12];
};

Assumption: 'seqid' does not refer to the seqid associated with the
nfs4_lockowner, but refers to the (formerly opaque) portion of the
stateid which is mutated on open/close/lock.

If this is correct, why was it decided to expose this part of the
stateid to the client?  I would actually prefer to have stateid's
be completely opaque (typedef opaque stateid4[16]) for two reasons:

1.  Delegation stateid's do not mutate, and therefore have no
associated seqid field.
2.  It seems more natural, given that stateids 0 and -1 have special
semantics (as pointed out by Dan from Hummingbird).

Is there some reason that I'm missing for making the "stateid seqid"
visible to the client?

Kendrick

---

From: "Dan Trufasiu" <[email-masked]>
Date: Fri, 5 Oct 2001 16:31:30 -0400

The stateid used to be an opaque structure for the client. Do I have to
consider that the new stateid4 is a read only structure (for the client)?
From my understanding: if I return back a stateid I have to return back what
I received from the server and I don't have to update the  seqid field. I'm
correct?

Thanks

Dan

> From: Noveck, Dave [mailto:[email-masked]]
> Sent: Friday, October 05, 2001 3:11 PM
> To: 'Kendrick M. Smith'; [email-masked]

---

From: Spencer Shepler <[email-masked]>
Date: Fri, 5 Oct 2001 16:03:11 -0500

Dave is correct.  The seqid within the stateid4 struct is to allow the
client the ability to determine which open response was the last one
(so that it can send the correct stateid back to the server on
subsequent requests).  This is mainly for the case of hardlinks where
the client is unable to determine that an object is the same until the
OPEN completes.  

As Dan observes and Dave confirms, the stateid4 is read-only for the
client.

I think that even with the current definition for stateid4, we can
come up with "special" stateids.  For example, a special staetid4
always has a seqid==0 and then the "other" member would be all-ones or
all-zeros.

Spencer

-- 

- Spencer -