On Thu, 2017-10-12 at 18:32 +0000, Thomas Haynes wrote:
> Hi Bruce,
>
> In this test:
>
> def testReplayCache006(t, env):
> """Send two solo sequence compounds with same seqid
>
> FLAGS: sequence all
> CODE: SEQ9f
> """
> c = env.c1.new_client(env.testname(t))
> sess = c.create_session()
> res1 = sess.compound([])
> check(res1)
> res2 = sess.compound([], cache_this=True, seq_delta=0)
> check(res2)
> res1.tag = res2.tag = ""
> if not nfs4lib.test_equal(res1, res2):
> fail("Replay results not equal")
>
> I don't see why the result should be NFS4_OK.
>
> The first compound does not set sa_cachethis and the second
> does set it. According to RFC5661, the server is not required
> to cache the first request if the client does not request it.
>
> And if the server does not cache the response, when it gets
> a request to replay it, it can return NFS4ERR_RETRY_UNCACHED_REP:
>
> 2.10.6.1.3. Optional Reply Caching
>
> On a per-request basis, the requester can choose to direct the
> replier to cache the reply to all operations after the first
> operation (SEQUENCE or CB_SEQUENCE) via the sa_cachethis or
> csa_cachethis fields of the arguments to SEQUENCE or CB_SEQUENCE.
> The reason it would not direct the replier to cache the entire
> reply
> is that the request is composed of all idempotent operations [34].
> Caching the reply may offer little benefit. If the reply is too
> large (see Section 2.10.6.4), it may not be cacheable anyway. Even
> if the reply to idempotent request is small enough to cache,
> unnecessarily caching the reply slows down the server and increases
> RPC latency.
>
> Whether or not the requester requests the reply to be cached has no
> effect on the slot processing. If the results of SEQUENCE or
> CB_SEQUENCE are NFS4_OK, then the slot's sequence ID MUST be
> incremented by one. If a requester does not direct the replier to
> cache the reply, the replier MUST do one of following:
>
> o The replier can cache the entire original reply. Even though
> sa_cachethis or csa_cachethis is FALSE, the replier is always
> free
> to cache. It may choose this approach in order to simplify
> implementation.
>
> o The replier enters into its reply cache a reply consisting of
> the
> original results to the SEQUENCE or CB_SEQUENCE operation, and
> with the next operation in COMPOUND or CB_COMPOUND having the
> error NFS4ERR_RETRY_UNCACHED_REP. Thus, if the requester later
> retries the request, it will get NFS4ERR_RETRY_UNCACHED_REP. If
> a
> replier receives a retried Sequence operation where the reply to
> the COMPOUND or CB_COMPOUND was not cached, then the replier,
>
> Further, since the parameters to SEQUENCE are different it is a false
> retry according to this:
>
> 2.10.6.1.3.1. False Retry
>
> If a requester sent a Sequence operation with a slot ID and sequence
> ID that are in the reply cache but the replier detected that the
> retried request is not the same as the original request, including a
> retry that has different operations or different arguments in the
> operations from the original and a retry that uses a different
> principal in the RPC request's credential field that translates to a
> different user, then this is a false retry. When the replier detects
> a false retry, it is permitted (but not always obligated) to return
> NFS4ERR_SEQ_FALSE_RETRY in response to the Sequence operation when it
> detects a false retry.
>
> I'm not sure if the test should be fixed to either
>
> 1) allow either NFS4_OK or NFS4ERR_RETRY_UNCACHED_REP
> 2) just remove the test.
>
> Thoughts?
Hmmm....
2.10.6.1.3
...
* MUST NOT return NFS4ERR_RETRY_UNCACHED_REP in reply to a
Sequence operation if the Sequence operation is the first
operation.
....
...so it looks as if the first sequence in a compound always has to
return either NFS_OK, or possibly NFS4ERR_SEQ_FALSE_RETRY. The latter
should presumably be allowed, since there is no exception carved out in
2.10.6.1.3.1 for the sequence op w.r.t. behaviour with different
operation arguments.
--
Trond Myklebust
Linux NFS client maintainer, PrimaryData
trond.myklebust@xxxxxxxxxxxxxxx
��.n��������+%������w��{.n�����{��w��� jg��� �����ݢj����G���� ���j:+v���w�m������w�������h�����٥
