Subject: [nfsv4] NFS4ERR_DELAY for sequenced ops

From: "Karandikar, Asmita" <[email-masked]>
Date: Mon, 20 Aug 2012 18:05:18 +0000

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

---

From: "Myklebust, Trond" <[email-masked]>
Date: Mon, 20 Aug 2012 18:18:17 +0000

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: [email-masked] [mailto:[email-masked]] On Behalf Of Karandikar, Asmita
Sent: Monday, August 20, 2012 2:05 PM
To: [email-masked]
Subject: [nfsv4] NFS4ERR_DELAY for sequenced ops

-Asmita

---

From: "Karandikar, Asmita" <[email-masked]>
Date: Mon, 20 Aug 2012 21:51:12 +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; [email-masked]
Subject: RE: NFS4ERR_DELAY for sequenced ops

Hi Asmita,

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

-Asmita

---

From: Rick Macklem <[email-masked]>
Date: Tue, 21 Aug 2012 07:37:07 -0400 (EDT)

Asmita Karandikar wrote:
> 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.
> 
> 
> 
> 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.
> 
Trond has already answered this, however...
Note also that you will need to increment the seqid number for the
open_owner4 if you return NFS4ERR_DELAY for Open, etc., since
NFS4ERR_DELAY is not in the list of errors that do not increment
it. (For 4.0, not 4.1 obviously.)
>From RFC3530 (around pg 73):

   The client MUST monotonically increment the sequence number for the
   CLOSE, LOCK, LOCKU, OPEN, OPEN_CONFIRM, and OPEN_DOWNGRADE
   operations.  This is true even in the event that the previous
   operation that used the sequence number received an error.  The only
   exception to this rule is if the previous operation received one of
   the following errors: NFS4ERR_STALE_CLIENTID, NFS4ERR_STALE_STATEID,
   NFS4ERR_BAD_STATEID, NFS4ERR_BAD_SEQID, NFS4ERR_BADXDR,
   NFS4ERR_RESOURCE, NFS4ERR_NOFILEHANDLE.
> 
> 
> 
> 
> -Asmita
> 
> 
> _______________________________________________
> nfsv4 mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/nfsv4

---

From: Rick Macklem <[email-masked]>
Date: Tue, 21 Aug 2012 07:52:23 -0400 (EDT)

> NFS4ERR_RESOURCE, NFS4ERR_NOFILEHANDLE.

Oops, and I forgot to mention that, because the seqid # has to be
incremented, I don't think allowing NFS4ERR_DELAY for OPEN_CONFIRM
would be a good plan, since its job is to confirm that seqid#.

rick