Re: [nfsv4] Benjamin Kaduk's Discuss on draft-ietf-nfsv4-rfc5661sesqui-msns-03: (with DISCUSS and COMMENT)

Benjamin Kaduk <> Mon, 13 January 2020 23:00 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 619C512004C; Mon, 13 Jan 2020 15:00:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Qpi1Se7JDiLM; Mon, 13 Jan 2020 14:59:59 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 6E20612001B; Mon, 13 Jan 2020 14:59:57 -0800 (PST)
Received: from ([]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by (8.14.7/8.12.4) with ESMTP id 00DMxoV5011517 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 13 Jan 2020 17:59:52 -0500
Date: Mon, 13 Jan 2020 14:59:50 -0800
From: Benjamin Kaduk <>
To: David Noveck <>
Cc:, Magnus Westerlund <>, The IESG <>, NFSv4 <>, "" <>
Message-ID: <>
References: <> <> <> <>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <>
User-Agent: Mutt/1.12.1 (2019-06-15)
Archived-At: <>
Subject: Re: [nfsv4] Benjamin Kaduk's Discuss on draft-ietf-nfsv4-rfc5661sesqui-msns-03: (with DISCUSS and COMMENT)
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NFSv4 Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 13 Jan 2020 23:00:04 -0000

Replying to myself: I wrote this in multiple sittings and somehow thought
the point I wanted to revise was in the other fork of the thread.

On Mon, Jan 13, 2020 at 02:54:11PM -0800, Benjamin Kaduk wrote:
> Hi David,
> Trimming lots of good stuff here as well...
> On Thu, Jan 02, 2020 at 10:09:02AM -0500, David Noveck wrote:
> > On Wed, Dec 18, 2019 at 3:32 AM Benjamin Kaduk via Datatracker <
> >> wrote:
> > 
> > > Benjamin Kaduk has entered the following ballot position for
> > > draft-ietf-nfsv4-rfc5661sesqui-msns-03: Discuss
> > >
> > > I note inline (in what is probably too many places; please don't reply
> > > at all of them!) some question about how clear the text is that a file
> > > system migration is something done at a per-file-system granularity, and
> > > that migrating a client at a time is not possible.
> > 
> > 
> > It might be possible but doing so is not a goal of this specfication.
> > 
> > I'm not sure how to address your concern.   I don't know why anyone would
> > assume that migrating entire clients is a goal of this specification.   As
> > far as
> > I can see, when the word "migration" is used it is always in connection with
> > migrating a file system.   Is there some specific place where you think
> > this
> > issue is likely to arise?
> I think I garbled my point; my apologies.
> To give a semi-concrete example, suppose I have clients A and B that are
> accessing filesystem F on server X, and filesystem F is also available on
> server Y.  If X decides that it needs to migrate access to F away from X
> (e.g., for maintenance), then the "file system migration event" involves
> telling both A and B to look to Y for access to F, at basically the same
> time.  If X tries to tell only A but not B to access F via Y but lets B
> continue to access F at X, then I think there can be some subtle
> consistency issues.
> In some sense, this is easy to consider as a dichotomy between "migration
> is for server maintenance" vs. "migration is for load balancing".  Assuming
> I understand correctly (not a trivial assumption!), there was never any
> intent to use these mechanisms for load balancing, and if we can explicitly
> disclaim such usage, then we don't have to try to reason through any
> potential subtle consistency issues.

Some of your later replies in the "comment-section" thread make me think
that my understanding, quoted above, is incorrect.  That is, that it's okay
for X to tell A to migrate to Y for filesystem F while X continues to serve
F to B.  In particular, the updated text about server reclaim behavior (and
knowing what specific clientids might be reclaiming) seems to address the
main "subtle consistency issues" that I can think of right now.

Sorry about that.