IETF Logo Mail Archive

Re: [nfsv4] 4.0 trunking

"J. Bruce Fields" <bfields@fieldses.org> Fri, 30 September 2016 20:52 UTC

Return-Path: <bfields@fieldses.org>
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 D507312B136 for <nfsv4@ietfa.amsl.com>; Fri, 30 Sep 2016 13:52:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.218
X-Spam-Level:
X-Spam-Status: No, score=-4.218 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-2.316, SPF_HELO_PASS=-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 bs3Kxhhxi5nC for <nfsv4@ietfa.amsl.com>; Fri, 30 Sep 2016 13:52:04 -0700 (PDT)
Received: from fieldses.org (fieldses.org [IPv6:2600:3c00::f03c:91ff:fe50:41d6]) by ietfa.amsl.com (Postfix) with ESMTP id 805DA12B029 for <nfsv4@ietf.org>; Fri, 30 Sep 2016 13:52:04 -0700 (PDT)
Received: by fieldses.org (Postfix, from userid 2815) id 1A0EE2415; Fri, 30 Sep 2016 16:52:04 -0400 (EDT)
Date: Fri, 30 Sep 2016 16:52:04 -0400
From: "J. Bruce Fields" <bfields@fieldses.org>
To: Andy Adamson <androsadamson@gmail.com>
Message-ID: <20160930205204.GA7570@fieldses.org>
References: <20160907212039.GA6847@fieldses.org> <CADaq8jfiRU7DTRYXGHZvMALAZWeRjhqcpo8Si3_diMt_5dNSMw@mail.gmail.com> <20160908010532.GA10658@fieldses.org> <CADaq8jcnananUPDHH4Vzhv93JTxZegsZLMCtZWFD-keHheKvHA@mail.gmail.com> <20160910200355.GA30688@fieldses.org> <BBB2EBDC-6F05-44C1-B45A-C84C24A9AD7F@netapp.com> <20160920213931.GC12789@fieldses.org> <CAHVgHyVrOW6qVRzDXqwxjh4n3dy-Up+kcSpzuTQon+cR1o9iYA@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <CAHVgHyVrOW6qVRzDXqwxjh4n3dy-Up+kcSpzuTQon+cR1o9iYA@mail.gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Archived-At: <https://mailarchive.ietf.org/arch/msg/nfsv4/W0O1D6O39kduClmMC6nSBTnEeFY>
Cc: "Adamson, Andy" <William.Adamson@netapp.com>, "nfsv4@ietf.org" <nfsv4@ietf.org>
Subject: Re: [nfsv4] 4.0 trunking
X-BeenThere: nfsv4@ietf.org
X-Mailman-Version: 2.1.17
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: Fri, 30 Sep 2016 20:52:06 -0000

On Fri, Sep 30, 2016 at 04:25:00PM -0400, Andy Adamson wrote:
> Chuck Lever and I are writing the IETF spec describing the use of
> fs_locations/fs_locations_info for client multipath discovery for
> NFSv4.1 non-pNFS or MDS server trunking. Do you think we should bother
> with the NFSv4.0 (clientID trunking) case?

My feeling is that the problems we saw with 4.0 trunking are pretty easy
to fix.  So don't take my complaints there as a reason to rule it out.

Like you, though, I'd rather ignore it.

The reason to do it would probably be to deliver this to people stuck on
older OS's without 4.1 support, but those OS's are getting increasingly
difficult to hack additional features into anyway.

If it were just me, I'd do the 4.1 case first.  Then if it looked like
the same basic approach would cover 4.0 too--hey, why not.

--b.

> 
> -->Andy
> 
> On Tue, Sep 20, 2016 at 5:39 PM, J. Bruce Fields <bfields@fieldses.org> wrote:
> > On Mon, Sep 12, 2016 at 12:59:05PM +0000, Adamson, Andy wrote:
> >> IMHO we should not worry too much about NFSv4.0 trunking as NFSv4.1+ solves this issue. Trunking is simply one more reason to move from NFSv4.0 to NFSv4.1.
> >
> > I tend to agree, but since it got implemented an was causing a real bug,
> > it was hard to ignore....
> >
> > After a patch (55b9df93ddd6 "NFSv4/v4.1: Verify the client owner id
> > during trunking detection", if anyone cares) the damage seems restricted
> > to the non-default "migration" case, making this less of a concern.
> >

v2.23.0 | Report a Bug | By Email