Subject: RE: [nfsv4] Open and seqids

From: "Noveck, Dave" <[email-masked]>
Date: Thu, 21 Oct 2004 10:03:57 -0400

> Section 8.1.5 talks about sequencing of lock requests. It states that
> for requests that contain a sequence number, for each lock_owner there
> should be no more than one outstanding request. 

I note that it doesn't say "must not", "SHOULD NOT", or "MUST NOT".

Lower case should-not is way down in the hierarchy of IETF modalities.
I think what it sort of means is "we've only really thought through
the case where you do this.  If you want to do otherwise, go ahead
but if you do, it's up to you to live with the the consequences."

> OPEN is one such
> request and for every open_owner there cannot be more than one
> outstanding request.

Well, there *should not* be more than one outstanding request.

> Section 2.2 in its definition of stateid4 states that seqid field
> should be monotonically incremented because clients will inspect seqid
> to determine correct order of OPEN processing done by server. This
> implies that there can be more than one outstanding open requests.

Right, it seems it would be unneeded if clients only had one outstanding
request for a given file-owner pair.  

> 1. How can there be more than 1 Open outstanding for an open_owner,
> when section 8.1.5 forbids it?

It doesn't forbid it.  It seems as if it deprecates it, treats it as
something in questionable taste, etc.

> 2. If the same open_owner opens a second file, then does it invalidate
> the first stateid obtained from first open?

No.

> Open(open_owner1, file1) => stateid1.
> Open(open_owner1, file2) => stateid2.

> Is stateid1 invalid now? Or can it still be used for read/write/close?

These two stateids will have separate opaque parts and the seqids for
each will have nothing to do with the other.  Seqid comparison only
comes into play when the opaque parts of two stateid's match and they
are thus part of the same stateid sequence.  Neither of the two
stateids above will invalidate the other.

_______________________________________________
nfsv4 mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/nfsv4

---

From: Spencer Shepler <[email-masked]>
Date: Thu, 21 Oct 2004 10:49:01 -0500

> something in questionable taste, etc.

We have been investigating having the Solaris client generate multiple
outstanding opens with the same open owner to gain more concurrency in
certain cases.  As Dave points out, if the client does this, then it
is responsible for recovering from errors like BAD_SEQID.

Spencer

---

From: David Robinson <[email-masked]>
Date: Thu, 21 Oct 2004 11:26:18 -0500

> but if you do, it's up to you to live with the the consequences."

I don't know the history of the exact language, but making this a
very strong MUST NOT is probably not necessary. Given the purpose
of sequence numbers to serialize, the rules primarily govern how
the server should process requests and really do not constrain
how a client should issue them. The server *MUST* process them
in order and it is well defined what it should do in response
to an out of order request (resend versus NFS4ERR_BAD_SEQID).

The text in 8.1.5 was written with both reliable and unreliable
transports in mind, with the acceptance that bogus routers and
switches may reinject past history at any time. Strictly defining
client behavior could allow a server to declare a client as
non-conforming as a result of bogus routers and take some drastic
step. That seems like a bad thing to do.

I view the client text as primarily informative of the expected
behavior. Issuing sequence numbers out of order is simply not
a very productive implementation. Issuing multiple concurrent
requests can be done, but such a client is betting that the
server will receive them in order and process them in order.
A client may be able to win that bet, but it must be prepared
to recover from the not unlikely case that the server responds
with a NFS4ERR_BAD_SEQID.

	-David