On 02/15/2012 02:46 AM, Myklebust, Trond wrote:
Hi Vitaliy.
What's wrong with sa_sequenceid == 0? I can't see anything in the spec
that states that the sequenceid is supposed to be initialised to 1.
That is good question.
In 2.10.6.1. "Slot Identifiers and Reply Cache":
A slot contains a sequence ID and the cached reply corresponding to
the request sent with that sequence ID. The sequence ID is a 32-bit
unsigned value, and is therefore in the range 0..0xFFFFFFFF (2^32 -
1). The first time a slot is used, the requester MUST specify a
sequence ID of one (Section 18.36).
In 18.36.4.4 "Session creation":
For each slot in the reply cache, the
server sets the sequence ID to zero, and records an entry
^^^^^^^^^
containing a COMPOUND reply with zero operations and the error
NFS4ERR_SEQ_MISORDERED. This way, if the first SEQUENCE request
sent has a sequence ID equal to zero, the server can simply
^^^^^^^^^^^^
return what is in the reply cache: NFS4ERR_SEQ_MISORDERED. The
client initializes its reply cache for receiving callbacks in the
same way, and similarly, the first CB_SEQUENCE operation on a
slot after session creation MUST have a sequence ID of one.
So sending "zero" sa_sequenceid is allowed.
But if Linux NFS server receives first OP_SEQUENCE with "sa_sequenceid
== 0", it replies "NFS4ERR_RETRY_UNCACHED_REP" (for OP_PUTROOTFH) - but
expected SEQ_MISORDERED for OP_SEQUENCE. Illumos NFSv4.1 implementation
returns allowed SEQ_MISORDERED.
So why just do not fix receiving error and correct sending sa_sequenceid
to 1?
--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
