pynfs replay cache test SEQ9f

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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?

--
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




[Index of Archives]     [Linux Filesystem Development]     [Linux USB Development]     [Linux Media Development]     [Video for Linux]     [Linux NILFS]     [Linux Audio Users]     [Yosemite Info]     [Linux SCSI]

  Powered by Linux