From: Noveck, Dave (Dave.Noveck@netapp.com)
Date: 10/05/01-02:10:55 PM Z
Message-ID: <8C610D86AF6CD4119C9800B0D0499E3333566F@red.nane.netapp.com>
From: "Noveck, Dave" <Dave.Noveck@netapp.com>
Subject: RE: changes to nfs4_prot.x / protocol description
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:kmsmith@umich.edu]
Sent: Friday, October 05, 2001 2:51 PM
To: nfsv4-wg@sunroof.eng.sun.com
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
This archive was generated by hypermail 2.1.2 : 03/04/05-01:49:15 AM Z CST