Re: [nfsv4] Benjamin Kaduk's Discuss on draft-ietf-nfsv4-rfc5661sesqui-msns-03: (with DISCUSS and COMMENT)
Benjamin Kaduk <kaduk@mit.edu> Wed, 22 January 2020 03:25 UTC
Return-Path: <kaduk@mit.edu>
X-Original-To: nfsv4@ietfa.amsl.com
Delivered-To: nfsv4@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C7A312002F; Tue, 21 Jan 2020 19:25:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r5pI8CMOPG4X; Tue, 21 Jan 2020 19:25:54 -0800 (PST)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C33DC120013; Tue, 21 Jan 2020 19:25:43 -0800 (PST)
Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 00M3PadP003330 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 21 Jan 2020 22:25:38 -0500
Date: Tue, 21 Jan 2020 19:25:35 -0800
From: Benjamin Kaduk <kaduk@mit.edu>
To: David Noveck <davenoveck@gmail.com>
Cc: The IESG <iesg@ietf.org>, draft-ietf-nfsv4-rfc5661sesqui-msns@ietf.org, nfsv4-chairs@ietf.org, Magnus Westerlund <magnus.westerlund@ericsson.com>, NFSv4 <nfsv4@ietf.org>
Message-ID: <20200122032535.GF80030@kduck.mit.edu>
References: <157665795217.30033.16985899397047966102.idtracker@ietfa.amsl.com> <CADaq8jegizL79V4yJf8=itMVUYDuHf=-pZgZEh-yqdT30ZdJ5w@mail.gmail.com> <20191223021435.GW35479@kduck.mit.edu> <CADaq8jetpqMbKgVj6xTHYqkeJZXL3WZsVgrRdooYhaK0S8uTVA@mail.gmail.com> <20200113182716.GH66991@kduck.mit.edu> <CADaq8jdELRzigMvsWsNGQmPUs0uqm2fJkuO9RPH=bXhd4q0qYw@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <CADaq8jdELRzigMvsWsNGQmPUs0uqm2fJkuO9RPH=bXhd4q0qYw@mail.gmail.com>
User-Agent: Mutt/1.12.1 (2019-06-15)
Archived-At: <https://mailarchive.ietf.org/arch/msg/nfsv4/B93Z5grVV8CLTnE4C7atZTxegUs>
Subject: Re: [nfsv4] Benjamin Kaduk's Discuss on draft-ietf-nfsv4-rfc5661sesqui-msns-03: (with DISCUSS and COMMENT)
X-BeenThere: nfsv4@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NFSv4 Working Group <nfsv4.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/nfsv4>, <mailto:nfsv4-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/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, 22 Jan 2020 03:25:56 -0000
On Sat, Jan 18, 2020 at 08:35:57AM -0500, David Noveck wrote: > On Mon, Jan 13, 2020 at 1:27 PM Benjamin Kaduk <kaduk@mit.edu> wrote: > > > Hi David, > > > > Lots of good stuff trimmed (and thank you for them!). Just one comment for > > this thread... > > > > On Thu, Jan 02, 2020 at 10:08:23AM -0500, David Noveck wrote: > > > On Sun, Dec 22, 2019 at 9:14 PM Benjamin Kaduk <kaduk@mit.edu> wrote: > > > > > > > On Fri, Dec 20, 2019 at 09:46:22AM -0500, David Noveck wrote: > > [...] > > > > > > In a similar "discuss discuss" vein, Section 11.10.8 describes a > > > > > > scenario that does not give much clarity, at a protocol level, into > > > > what > > > > > > degree of replication synchronization a client can expect from a > > given > > > > > > file system that advertises multiple replicas. I recognize that > > this > > > > is > > > > > > de facto just stating the deployed reality, but it's also hard to > > feel > > > > > > good about having this level of ambiguity in a propsed standard, > > > > > > > > > > It gets easier over time. Sigh! This would be the fourth Proposed > > > > > Standard with this issue :-( > > > > > > > > > > Still I think we can do a bit better by relyimg on the three special > > > > cases > > > > > listed at > > > > > the end of that section and adding something like the following > > after the > > > > > list: > > > > > > > > > > When none of these special situations apply, there is no basis, > > > > > within the protool, for the client making assumptions about the > > > > > contents of a replica file ststem and its relationship to previous > > > > > file sytem instances. This may mean that switching between file > > > > > system that are not read-only is not available, where either the > > > > > > > > Hmm, do we want to add a descriptor like "nominally identical" to "file > > > > systems" (note: plural) > > > > > > > > > > Will do. > > > > > > > > > > > > > > > client does not use or the server does not support the > > > > > fs_locations_info atribute. > > > > > > > > That helps some. We might consider a note in the first paragraph (near > > > > "The namespace will typically be constructed") about the details of > > that > > > > being configured in an out-of-band manner. > > > > > > > > > > I don't think details can be provided since this is pretty much up to the > > > server although we can make it clear that the server constructs this on > > > the basis of what it knows about the file system and their > > characteristics, > > > i.e information not really part of the protocol. > > > > > > How about:. > > > > > > The server is responsible for contructing an appropriate namespace. > > > Typically, it is contructed so that applications can choose an > > > appropriate > > > level of support, so that in one position in the namespace a varied > > set > > > of replicas might be listed, while in another only those that are > > > up-to-date > > > would be considered replicas. > > > > > > > > > I'll think about doing that. > > > > I'm not so much concerned about how the server constructs the namespace (as > > the current practice leaves that entirely up to the server), but rather how > > the client, or some human associated with the client, learns what the > > server did. That is, having a fancy namespace with extra semantics doesn't > > do you any good if no one else knows what those semantics are :) > > I was just hoping that this document could be more explicit about "this > > protocol doesn't give you a way to communicate the extra semantics from > > server to client, but you probably want to do it somehow". I don't mind > > giving more details about the types of semantics a server might encode in > > the namespace as well, but that's not the direction I was trying to push > > in. > > > > OK. I think I can address your concerns but it needs to be pointed out > that > in many cases of the "extra" semanntics we are talking about, the semantics > are clear. This is true of trunking, referrals and migration. In the > case of > "replication", we do have a lot of existing uncertainty and I will try to > put in the > kind of text you suggest. > > This and related issues have been mentioned in a number of sub-threads and > I intend to > consolidate text addressing them here. I'm going to propose that we > address all > these issues by some additions to Section 11.5.4. Specfically I propose > revsing the > the second paragrapgh and adding a new tthird pragraph so that the last two > paragraphs > read as follows; > > In the event that the occurrence of server failures, communications > problems, or other difficulties make continued access to the current > file system impossible or otherwise impractical, the client can use > the alternate locations as a way to get continued access to its data. > > The alternate locations may be physical replicas of the (typically > read-only) file system data supplemneted by possible asynchronous (nit: "supplemented", though I made the same typo myself just now) > propagation of updates. Alternatively, they may provide for the use > of various forms of server clustering in which multiple servers > provide alternate ways of accessing the same physical file system. > How the difference between replicas affects file system transitions > can be represented within the fs_locations and fs_locations_info > attributes and how the client deals with file system transition > issues will be discussed in detail in later sections. > > Although the location attributes provide some information about the > nature of the inter-replica transition, many aspects of the semantics > of posible asynchronous updates are not currently described by the > protocol, making it necessary that clients using replication to > switch among replicas undergoing change familiarize themselves with > the semantics of the update approach used. Because of this lack of > specificity, many applications may find use of migration more > appropiate, since, in that case, the server, when effecting the > transition, has established a point in time such that all updates > made before that can propagated to the new replica as part of the > migration event. Thanks, this covers the key point I was concerned about. -Ben
- [nfsv4] Benjamin Kaduk's Discuss on draft-ietf-nf… Benjamin Kaduk via Datatracker
- Re: [nfsv4] Benjamin Kaduk's Discuss on draft-iet… David Noveck
- Re: [nfsv4] Benjamin Kaduk's Discuss on draft-iet… Benjamin Kaduk
- Re: [nfsv4] Benjamin Kaduk's Discuss on draft-iet… David Noveck
- [nfsv4] Benjamin Kaduk's Discuss on draft-ietf-nf… David Noveck
- Re: [nfsv4] Benjamin Kaduk's Discuss on draft-iet… Benjamin Kaduk
- Re: [nfsv4] Benjamin Kaduk's Discuss on draft-iet… Benjamin Kaduk
- Re: [nfsv4] Benjamin Kaduk's Discuss on draft-iet… Benjamin Kaduk
- Re: [nfsv4] Benjamin Kaduk's Discuss on draft-iet… David Noveck
- Re: [nfsv4] Benjamin Kaduk's Discuss on draft-iet… David Noveck
- Re: [nfsv4] Benjamin Kaduk's Discuss on draft-iet… Benjamin Kaduk
- Re: [nfsv4] Benjamin Kaduk's Discuss on draft-iet… Benjamin Kaduk
- Re: [nfsv4] Benjamin Kaduk's Discuss on draft-iet… David Noveck
- Re: [nfsv4] Benjamin Kaduk's Discuss on draft-iet… Magnus Westerlund