[nfsv4] 3530bis Issue 37: More ops need to be able to return LEASE_MOVED

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

Return-Path: <Robert.Thurlow@oracle.com>
X-Original-To: nfsv4@core3.amsl.com
Delivered-To: nfsv4@core3.amsl.com
Received: from localhost (localhost []) by core3.amsl.com (Postfix) with ESMTP id 999583A723E for <nfsv4@core3.amsl.com>; Wed, 6 Oct 2010 13:19:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([]) by localhost (core3.amsl.com []) (amavisd-new, port 10024) with ESMTP id 44d5xD-dVxIf for <nfsv4@core3.amsl.com>; Wed, 6 Oct 2010 13:19:14 -0700 (PDT)
Received: from rcsinet10.oracle.com (rcsinet10.oracle.com []) by core3.amsl.com (Postfix) with ESMTP id 0B8A93A724B for <nfsv4@ietf.org>; Wed, 6 Oct 2010 13:19:13 -0700 (PDT)
Received: from rcsinet13.oracle.com (rcsinet13.oracle.com []) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id o96KKDHY008890 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for <nfsv4@ietf.org>; Wed, 6 Oct 2010 20:20:14 GMT
Received: from acsmt354.oracle.com (acsmt354.oracle.com []) by rcsinet13.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o96Hi8SW016897 for <nfsv4@ietf.org>; Wed, 6 Oct 2010 20:20:13 GMT
Received: from abhmt003.oracle.com by acsmt354.oracle.com with ESMTP id 660361921286396412; Wed, 06 Oct 2010 13:20:12 -0700
Received: from [] (/ by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 06 Oct 2010 13:20:12 -0700
Message-ID: <4CACD9BB.3070500@oracle.com>
Date: Wed, 06 Oct 2010 14:19:07 -0600
From: Robert Thurlow <Robert.Thurlow@oracle.com>
User-Agent: Thunderbird (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 37: More ops need to be able to return LEASE_MOVED
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:19:15 -0000

Hi folks,

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

In implementing NFSv4 migration support, we ran into a few more
ops which we believe should be able to return NFS4ERR_LEASE_MOVED.
The reason we have LEASE_MOVED is to notify the client that some
other filesystem it has used has migrated, and that it should react
to that to preserve its state.  Operations which include state
tokens should help with notification by failing with LEASE_MOVED.

The following OPs use state but do not now return LEASE_MOVED:
         SETATTR (when the file size is set)

IIRC from the 3530bis call, there were questions about whether
it was a good idea for OPEN_CONFIRM to return LEASE_MOVED.  I
believe it is, since state is used in the operation.  A possible
counter-argument is that delay can be inserted between OPEN and
OPEN_CONFIRM for LEASE_MOVED handling, leading to unconfirmed
open state being discarded, which is at least inconvenient.  A
server could of course choose to extend timeouts for a client
that had been sent a LEASE_MOVED notification.

If someone remembers a reason why one of these ops should not
return LEASE_MOVED, or you wish to comment on the above, please
let us know.

Rob T