IETF Logo Mail Archive

Re: [nfsv4] NFS4ERR_DELAY for sequenced ops

"Karandikar, Asmita" <Asmita.Karandikar@netapp.com> Mon, 20 August 2012 21:51 UTC

Return-Path: <Asmita.Karandikar@netapp.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 602BC21F85AF for <nfsv4@ietfa.amsl.com>; Mon, 20 Aug 2012 14:51:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.598
X-Spam-Level:
X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TgIWAisDS134 for <nfsv4@ietfa.amsl.com>; Mon, 20 Aug 2012 14:51:15 -0700 (PDT)
Received: from mx2.netapp.com (mx2.netapp.com [216.240.18.37]) by ietfa.amsl.com (Postfix) with ESMTP id F244421F85AE for <nfsv4@ietf.org>; Mon, 20 Aug 2012 14:51:14 -0700 (PDT)
X-IronPort-AV: E=Sophos; i="4.77,799,1336374000"; d="scan'208,217"; a="678679336"
Received: from smtp2.corp.netapp.com ([10.57.159.114]) by mx2-out.netapp.com with ESMTP; 20 Aug 2012 14:51:14 -0700
Received: from vmwexceht04-prd.hq.netapp.com (vmwexceht04-prd.hq.netapp.com [10.106.77.34]) by smtp2.corp.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id q7KLpDiU008842 for <nfsv4@ietf.org>; Mon, 20 Aug 2012 14:51:14 -0700 (PDT)
Received: from SACEXCMBX04-PRD.hq.netapp.com ([169.254.6.233]) by vmwexceht04-prd.hq.netapp.com ([10.106.77.34]) with mapi id 14.02.0309.002; Mon, 20 Aug 2012 14:51:13 -0700
From: "Karandikar, Asmita" <Asmita.Karandikar@netapp.com>
To: "Myklebust, Trond" <Trond.Myklebust@netapp.com>, "nfsv4@ietf.org" <nfsv4@ietf.org>
Thread-Topic: NFS4ERR_DELAY for sequenced ops
Thread-Index: Ac1+/kC/brhzrGXjQTCU+1+gGWf7kgAAGFKwAAeOPIA=
Date: Mon, 20 Aug 2012 21:51:12 +0000
Message-ID: <1C38CAC82B45E74AA73E7D672ACA92CE3E1E32@SACEXCMBX04-PRD.hq.netapp.com>
References: <1C38CAC82B45E74AA73E7D672ACA92CE3E0244@SACEXCMBX04-PRD.hq.netapp.com> <4FA345DA4F4AE44899BD2B03EEEC2FA93BF8F0@SACEXCMBX04-PRD.hq.netapp.com>
In-Reply-To: <4FA345DA4F4AE44899BD2B03EEEC2FA93BF8F0@SACEXCMBX04-PRD.hq.netapp.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.106.53.53]
Content-Type: multipart/alternative; boundary="_000_1C38CAC82B45E74AA73E7D672ACA92CE3E1E32SACEXCMBX04PRDhqn_"
MIME-Version: 1.0
Subject: Re: [nfsv4] NFS4ERR_DELAY for sequenced ops
X-BeenThere: nfsv4@ietf.org
X-Mailman-Version: 2.1.12
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: <http://www.ietf.org/mail-archive/web/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: Mon, 20 Aug 2012 21:51:16 -0000

Sorry, I missed out LOCKU operation. I guess we are good with OPEN_CONFIRM. I don't have a particular scenario in mind.

-Asmita

From: Myklebust, Trond
Sent: Monday, August 20, 2012 11:18 AM
To: Karandikar, Asmita; nfsv4@ietf.org
Subject: RE: NFS4ERR_DELAY for sequenced ops

Hi Asmita,

NFS4ERR_DELAY is listed as a valid error for both OPEN, and CLOSE in RFC3530 (see sections 14.2.16 and 14.2.2).
draft-ietf-nfsv4-rfc3530bis-18.txt, also lists OPEN and CLOSE, and adds OPEN_DOWNGRADE in section 13.4.

So, the only missing operation would be OPEN_CONFIRM. Could you please explain why you'd need to return NFS4ERR_DELAY here? Why would you want to return 'success' to the OPEN call, but NFS4ERR_DELAY to the OPEN_CONFIRM?

Cheers
  Trond

From: nfsv4-bounces@ietf.org [mailto:nfsv4-bounces@ietf.org] On Behalf Of Karandikar, Asmita
Sent: Monday, August 20, 2012 2:05 PM
To: nfsv4@ietf.org
Subject: [nfsv4] NFS4ERR_DELAY for sequenced ops


The 3530 RFC doesn't specify NFS4ERR_DELAY as a valid error for sequenced ops - OPEN, CLOSE, OPEN_CONFIRM and OPEN_DOWNGRADE.
In Data ONTAP, if we cannot process a request because we are waiting on some resource, we return back NFS4ERR_DELAY so that the client can come back and try.

NFS4ERR_DELAY not being an allowed error for these ops, we are forced to return NFS4ERR_RESOURCE which is not a transient error and results in the client returning an error to the application which is undesired.

I would like to get NFS4ERR_DELAY included as one of the allowable errors for sequenced ops.

We can add this in the 3530bis and 5661 errata. It should be ok to do so because the application will not see any change in behavior. The NFS client will retry on seeing NFS4ERR_DELAY. Also, this does not introduce any POSIX change.


-Asmita

v2.23.0 | Report a Bug | By Email