Subject: [nfsv4] Comments on NFSv41 I-D 18 layouts and sequence ids.

From: [email-masked]
Date: Fri, 11 Jan 2008 13:02:48 -0500

In section 12.5.5.2.1.2

   Consider a pNFS client that has sent a LAYOUTGET and then receives a
   CB_LAYOUTRECALL for the same file...

   Note
   that in the first case, the "seqid" in the layout stateid of the
   recall is one greater than what the client has recorded and in the
   second case, the "seqid" is equal to what the client has recorded.
   This allows the client to disambiguate between the two cases.  The
   client thus knows precisely which possibility applies.

The discussion in the spec holds for the simple case of a client sending
a LAYOUTGET more or less simultaneously with a server sending a
CB_LAYOUTRECALL.  The situation though is more complicated if we
consider that a client may have multiple LAYOUTGET operations
outstanding when the server sends a CB_LAYOUTRECALL operation.  It is
not longer the case that the seqid in the CB_LAYOUTRECALL is "one
greater that what the client as recorded".  With 'n' outstanding
LAYOUTGET operations on the same file, the seqid would have to be 'n'
greater than what is recorded for the first case to apply.

With respect to the seqid being "equal to what the client has recorded",
the second case applies whenever the seqid is less than "n plus what the
client has recorded".

I think the language should describe the more complicated case rather
than the simple case, so as to provide as much guidance as possible to
implementers.

-Jason

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

---

From: Mike Eisler <[email-masked]>
Date: Fri, 11 Jan 2008 12:00:48 -0800 (PST)

Suggested text is welcome. Otherwise, I'm inclined to leave it as it.

---

From: Benny Halevy <[email-masked]>
Date: Sat, 12 Jan 2008 22:53:27 +0200

[email-masked] wrote:
>    CB_LAYOUTRECALL for the same file…
>
>    Note
> The discussion in the spec holds for the simple case of a client 
> sending a LAYOUTGET more or less simultaneously with a server sending 
> a CB_LAYOUTRECALL. The situation though is more complicated if we 
> not longer the case that the seqid in the CB_LAYOUTRECALL is “one 
> greater that what the client as recorded”. With ‘n’ outstanding 
> LAYOUTGET operations on the same file, the seqid would have to be ‘n’ 
> With respect to the seqid being “equal to what the client has 
> recorded”, the second case applies whenever the seqid is less than “n 
> plus what the client has recorded”.
>
I thought so too but apparently that's untrue. The client does not 
increment the seqid on its own when it sends multiple, parallel requests.
It just sends the last seqid it knows about. The requests may be 
processed in any order on the server (when sent in different compounds) 
and the client determines their execution order, if needed, using the 
seqid on the respective _replies_.

Now, let's find where that's written in the spec :)

Benny
> ------------------------------------------------------------------------
>

---

From: Mike Eisler <[email-masked]>
Date: Sat, 12 Jan 2008 14:09:38 -0800 (PST)

> >    CB_LAYOUTRECALL for the same file…

   1. The server processed the LAYOUTGET before issuing the recall, 
      so the LAYOUTGET response is in flight, and must be waited for
      because it may be carrying layout info that will need to be 
      returned to deal with the CB_LAYOUTRECALL.

   2. The server sent the callback before receiving the LAYOUTGET. 
      The server will not respond to the LAYOUTGET until the
CB_LAYOUTRECALL 
      is processed.

> Now, let's find where that's written in the spec :)

The spec says.

``After the layout stateid is established, the "seqid" is incremented
by the server in each subsequent LAYOUTGET and LAYOUTRETURN response,
and in each CB_LAYOUTRECALL request. When the client fully processes
the response to a LAYOUTGET or LAYOUTRETURN, or fully processes the
arguments of a CB_LAYOUTRECALL, it MUST use the seqid of the stateid of
the reply from LAYOUTGET and LAYOUTRETURN, or the stateid in the
arguments of CB_LAYOUTRECALL, the client MUST use the seqid on
subsequent calls to LAYOUTGET or LAYOUTRETURN. ''

However, in reading this, I see that 

> >    second case, the "seqid" is equal to what the client has

is wrong, because CB_LAYOUTRECALL increments the seqid.

Instead, it should be:

   Note that in the first case, the "seqid" in the layout stateid of
the
   recall is *two* greater than what the client has recorded and in the
   second case, the "seqid" is *one* greater than what the client has
recorded.

---

From: [email-masked]
Date: Mon, 14 Jan 2008 14:18:01 -0500

I agree that it should be "one greater" and "two greater".
-Jason

-----Original Message-----
From: Mike Eisler [mailto:[email-masked]] 
Sent: Saturday, January 12, 2008 5:10 PM
To: [email-masked]
Subject: Re: [nfsv4] Comments on NFSv41 I-D 18 layouts and sequence ids.

> > With respect to the seqid being "equal to what the client has 
> > recorded", the second case applies whenever the seqid is less than
> "n 
> > plus what the client has recorded".
> >

The spec says.

Instead, it should be: