IETF Logo Mail Archive

Re: [nfsv4] "Courtesy locks"

Mike Mackovitch <macko@apple.com> Tue, 14 September 2010 15:57 UTC

Return-Path: <macko@apple.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 9F7603A69A8 for <nfsv4@core3.amsl.com>; Tue, 14 Sep 2010 08:57:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.599
X-Spam-Level:
X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
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 xjJ0bCMKcMQg for <nfsv4@core3.amsl.com>; Tue, 14 Sep 2010 08:57:10 -0700 (PDT)
Received: from mail-out4.apple.com (mail-out4.apple.com [17.254.13.23]) by core3.amsl.com (Postfix) with ESMTP id 8E3773A6991 for <nfsv4@ietf.org>; Tue, 14 Sep 2010 08:57:10 -0700 (PDT)
Received: from relay14.apple.com (relay14.apple.com [17.128.113.52]) by mail-out4.apple.com (Postfix) with ESMTP id 904B3AF5CE06; Tue, 14 Sep 2010 08:57:36 -0700 (PDT)
X-AuditID: 11807134-b7cacae0000058e0-52-4c8f9b6fe9a9
Received: from m12.macko.edu (il0102b-dhcp52.apple.com [17.201.26.102]) (using TLS with cipher AES256-SHA (AES256-SHA/256 bits)) (Client did not present a certificate) by relay14.apple.com (Apple SCV relay) with SMTP id 81.02.22752.07B9F8C4; Tue, 14 Sep 2010 08:57:36 -0700 (PDT)
Date: Tue, 14 Sep 2010 08:57:35 -0700
From: Mike Mackovitch <macko@apple.com>
To: Rick Macklem <rmacklem@uoguelph.ca>
Message-ID: <20100914155735.GA51698@m12.macko.edu>
References: <20100914000019.GA48838@m12.macko.edu> <874825331.864357.1284426810883.JavaMail.root@erie.cs.uoguelph.ca>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <874825331.864357.1284426810883.JavaMail.root@erie.cs.uoguelph.ca>
User-Agent: Mutt/1.5.20 (2009-06-14)
X-Brightmail-Tracker: AAAAAA==
Cc: nfsv4@ietf.org
Subject: Re: [nfsv4] "Courtesy locks"
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: Tue, 14 Sep 2010 15:57:11 -0000

On Mon, Sep 13, 2010 at 09:13:30PM -0400, Rick Macklem wrote:
> > 
> > But if the server is not allowed to process reclaim ops outside the
> > grace period then there's no hope of nicely handling the case where
> > the server's grace period passes before the client gets a chance to
> > reconnect to the server.
> 
> Yep. But grace periods must be greater than a lease duration and I'd
> assume clients will be trying hard to re-connect.

Yes.  But sometimes NFS client code doesn't have control over all the
network links between it and the server (e.g. a VPN that needs to be
reconnected by the user).

--macko

v2.23.0 | Report a Bug | By Email