[nfsv4] 3530bis Issue 40: NFS4ERR_LEASE_MOVED trumps NFS4ERR_CB_PATH_DOWN

Robert Thurlow <Robert.Thurlow@oracle.com> Wed, 06 October 2010 20:21 UTC

Return-Path: <Robert.Thurlow@oracle.com>
X-Original-To: nfsv4@core3.amsl.com
Delivered-To: nfsv4@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8308A3A71B0 for <nfsv4@core3.amsl.com>; Wed, 6 Oct 2010 13:21:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level:
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nzlboCH6PP52 for <nfsv4@core3.amsl.com>; Wed, 6 Oct 2010 13:21:12 -0700 (PDT)
Received: from rcsinet10.oracle.com (rcsinet10.oracle.com [148.87.113.121]) by core3.amsl.com (Postfix) with ESMTP id A34013A7004 for <nfsv4@ietf.org>; Wed, 6 Oct 2010 13:21:12 -0700 (PDT)
Received: from rcsinet13.oracle.com (rcsinet13.oracle.com [148.87.113.125]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id o96KMClh013459 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for <nfsv4@ietf.org>; Wed, 6 Oct 2010 20:22:13 GMT
Received: from acsmt355.oracle.com (acsmt355.oracle.com [141.146.40.155]) by rcsinet13.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o96KMB0D021617 for <nfsv4@ietf.org>; Wed, 6 Oct 2010 20:22:11 GMT
Received: from abhmt013.oracle.com by acsmt354.oracle.com with ESMTP id 660362241286396416; Wed, 06 Oct 2010 13:20:16 -0700
Received: from [10.7.250.62] (/10.7.250.62) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 06 Oct 2010 13:20:16 -0700
Message-ID: <4CACD9C2.8020803@oracle.com>
Date: Wed, 06 Oct 2010 14:19:14 -0600
From: Robert Thurlow <Robert.Thurlow@oracle.com>
User-Agent: Thunderbird 2.0.0.16 (X11/20080811)
MIME-Version: 1.0
To: NFSv4 <nfsv4@ietf.org>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Subject: [nfsv4] 3530bis Issue 40: NFS4ERR_LEASE_MOVED trumps NFS4ERR_CB_PATH_DOWN
X-BeenThere: nfsv4@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: NFSv4 Working Group <nfsv4.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/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: Wed, 06 Oct 2010 20:21:13 -0000

Hi folks,

This is issue 40 from http://github.com/loghyr/3530bis/blob/master/tasklist.txt.

In implementing NFSv4 migration support, we see a need to
clarify what happens when a server is in a position to return
both NFS4ERR_LEASE_MOVED and NFS4ERR_CB_PATH_DOWN, e.g. the
server knows it cannot make a callback to the client and it
knows the client is unaware of a migration event.

Our proposed wording change would require a server to hand
out NFS4ERR_LEASE_MOVED first, since the scope of the
condition involves another server which the client may
not know about yet.  Also, if the client handles the
NFS4ERR_CB_PATH_DOWN condition first by re-establishing the
callback path, it can get a recall it cannot respond to since
even DELEGRETURN will still fail with NFS4ERR_LEASE_MOVED.
This appears to lead to trying to handle recovery while
doing recovery, which does not seem good.

On the 3530bis call, some were not sure of the need to
mandate an ordering.  If that is your position, please let
us know why you don't agree with the above.

Thanks,
Rob T