[nfsv4] pynfs replay cache test SEQ9f

Thomas Haynes <loghyr@primarydata.com> Thu, 12 October 2017 18:32 UTC

Return-Path: <loghyr@primarydata.com>
X-Original-To: nfsv4@ietfa.amsl.com
Delivered-To: nfsv4@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C73A126DD9 for <nfsv4@ietfa.amsl.com>; Thu, 12 Oct 2017 11:32:18 -0700 (PDT)
X-Quarantine-ID: <3tLGiHJjI6rN>
X-Virus-Scanned: amavisd-new at amsl.com
X-Amavis-Alert: BANNED, message contains text/plain,.exe
X-Spam-Flag: NO
X-Spam-Score: -2.701
X-Spam-Level:
X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=primarydata.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3tLGiHJjI6rN for <nfsv4@ietfa.amsl.com>; Thu, 12 Oct 2017 11:32:16 -0700 (PDT)
Received: from us-smtp-delivery-194.mimecast.com (us-smtp-delivery-194.mimecast.com [216.205.24.194]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4B1E5129A89 for <nfsv4@ietf.org>; Thu, 12 Oct 2017 11:32:16 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=primarydata.com; s=mimecast20170802; t=1507833135; h=from:subject:date:message-id:to:cc:mime-version:content-type:content-transfer-encoding:in-reply-to:references; bh=ce9ISptlDNCq28A7hVPXX4ci4RGZb99BwDej5TgQink=; b=XDWMDVHdH7qP6vgtq825CbC3hgrBA+I52MBwKIoS/JWHuZJ9wX59jmqbuFpD0v+Xav3vtt6Gjed3o3oOWh5x4XTnA0ZM0J1GSfR1JUrnZEKy9o6aLuuqY7EIWd1LujwtexkZvJivjovldMRIfoLRuPWdIyd+9eE5UuJokkXVl6A=
Received: from NAM03-CO1-obe.outbound.protection.outlook.com (mail-co1nam03lp0022.outbound.protection.outlook.com [216.32.181.22]) (Using TLS) by us-smtp-1.mimecast.com with ESMTP id us-mta-45-4clrAv8NPiS0FQ7D93Ncug-1; Thu, 12 Oct 2017 14:32:13 -0400
Received: from BY2PR1101MB1093.namprd11.prod.outlook.com (10.164.166.21) by BY2PR1101MB1095.namprd11.prod.outlook.com (10.164.166.23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.77.7; Thu, 12 Oct 2017 18:32:09 +0000
Received: from BY2PR1101MB1093.namprd11.prod.outlook.com ([10.164.166.21]) by BY2PR1101MB1093.namprd11.prod.outlook.com ([10.164.166.21]) with mapi id 15.20.0077.020; Thu, 12 Oct 2017 18:32:09 +0000
From: Thomas Haynes <loghyr@primarydata.com>
To: "J. Bruce Fields" <bfields@fieldses.org>
CC: Mailing List Linux NFS <linux-nfs@vger.kernel.org>, "nfsv4@ietf.org" <nfsv4@ietf.org>
Thread-Topic: pynfs replay cache test SEQ9f
Thread-Index: AQHTQ4hpqhJXLnY7EUKrQkdcKBXIEA==
Date: Thu, 12 Oct 2017 18:32:09 +0000
Message-ID: <E0161195-9F4A-4B36-A71D-6A924498C893@primarydata.com>
References: <1507740502-5151-1-git-send-email-Thomas.Haynes@primarydata.com>
In-Reply-To: <1507740502-5151-1-git-send-email-Thomas.Haynes@primarydata.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [63.157.6.18]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; BY2PR1101MB1095; 20:2911HpFBWsFuh9edV/3njX+aq4+ogkD1c57JYoOzsxDnfwUo19BOuJ298a2JwfAJWuEr0wHS7nKcLi4w/FkR0vqfEN88OhWTSpp661jr+nhrTqvLUS7gX54MiJqpMZkGtjpqA/YmjJWpPZoSpZHc4xqFbzW3tF72rrxbwuMK7f8=
x-ms-exchange-antispam-srfa-diagnostics: SSOS;
x-ms-office365-filtering-correlation-id: 2e0af58e-2199-46ba-5850-08d5119f8c58
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254152)(2017082002075)(2017052603199)(201703131423075)(201702281549075); SRVR:BY2PR1101MB1095;
x-ms-traffictypediagnostic: BY2PR1101MB1095:
x-exchange-antispam-report-test: UriScan:(158342451672863);
x-microsoft-antispam-prvs: <BY2PR1101MB109525B586B3F4D0AEDE1406CE4B0@BY2PR1101MB1095.namprd11.prod.outlook.com>
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(8121501046)(5005006)(100000703101)(100105400095)(10201501046)(3002001)(93006095)(93001095)(6041248)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123558100)(20161123555025)(20161123560025)(20161123562025)(20161123564025)(2016111802025)(6072148)(6043046)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:BY2PR1101MB1095; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:BY2PR1101MB1095;
x-forefront-prvs: 04583CED1A
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39830400002)(376002)(346002)(199003)(189002)(60444003)(53936002)(5660300001)(316002)(7736002)(66066001)(3280700002)(54906003)(3660700001)(305945005)(97736004)(6512007)(102836003)(2950100002)(2906002)(99286003)(6116002)(3846002)(6916009)(478600001)(189998001)(82746002)(36756003)(86362001)(14454004)(8936002)(68736007)(105586002)(4326008)(6486002)(77096006)(2900100001)(6436002)(76176999)(54356999)(83716003)(106356001)(50986999)(8676002)(81166006)(25786009)(33656002)(81156014)(101416001)(6506006)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR1101MB1095; H:BY2PR1101MB1093.namprd11.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en;
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-ID: <1057EA442C3C9F47965ADCCCFA1486AB@namprd11.prod.outlook.com>
MIME-Version: 1.0
X-OriginatorOrg: primarydata.com
X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Oct 2017 18:32:09.2677 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 03193ed6-8726-4bb3-a832-18ab0d28adb7
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR1101MB1095
X-MC-Unique: 4clrAv8NPiS0FQ7D93Ncug-1
Content-Type: text/plain; charset="WINDOWS-1252"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/nfsv4/lQ_g3C2aznAZ6yZLnqunQ6s04Uo>
Subject: [nfsv4] pynfs replay cache test SEQ9f
X-BeenThere: nfsv4@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NFSv4 Working Group <nfsv4.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/nfsv4>, <mailto:nfsv4-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/nfsv4/>
List-Post: <mailto:nfsv4@ietf.org>
List-Help: <mailto:nfsv4-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/nfsv4>, <mailto:nfsv4-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 12 Oct 2017 18:32:18 -0000

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?