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

Benjamin Kaduk <[email protected]> Mon, 13 Jan 2020 14:59:50 -0800
Newsgroups gmane.ietf.nfsv4
Message-ID <[email protected]>
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 <
> > [email protected]> 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.

-Ben

_______________________________________________
nfsv4 mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/nfsv4