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