[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
- [nfsv4] 3530bis Issue 40: NFS4ERR_LEASE_MOVED tru… Robert Thurlow
- Re: [nfsv4] 3530bis Issue 40: NFS4ERR_LEASE_MOVED… Robert Thurlow