Return-Path: Received: from mx144.netapp.com ([216.240.21.25]:30431 "EHLO mx144.netapp.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753607AbcD2PyB (ORCPT ); Fri, 29 Apr 2016 11:54:01 -0400 From: Anna Schumaker Subject: Re: [PATCH Version 3 0/2] Add multihostname support for NFSv4.1,2 To: Steve Dickson , Chuck Lever References: <1461771407-16423-1-git-send-email-andros@netapp.com> <57236BB6.50103@RedHat.com> <1461940027554.14958@netapp.com> <572373BE.4000201@RedHat.com> <986CAF0C-495D-4085-A078-6B6A65CCB686@oracle.com> <572382B3.3070606@RedHat.com> CC: "Adamson, Andy" , Trond Myklebust , Linux NFS Mailing List Message-ID: <7ca4a3bd-43bf-1557-1141-4b96f5a32e40@Netapp.com> Date: Fri, 29 Apr 2016 11:53:51 -0400 MIME-Version: 1.0 In-Reply-To: <572382B3.3070606@RedHat.com> Content-Type: text/plain; charset="utf-8" Sender: linux-nfs-owner@vger.kernel.org List-ID: On 04/29/2016 11:50 AM, Steve Dickson wrote: > > > On 29/04/16 11:24, Chuck Lever wrote: >> >>> On Apr 29, 2016, at 10:46 AM, Steve Dickson wrote: >>> >>> >>> >>> On 04/29/2016 10:27 AM, Adamson, Andy wrote: >>>> Hi Steve >>>> >>>> Yes, if we decide to keep the multiple hostname option, then a man page update is required. I don't think we have a consensus on using the multiple hostname mount option as a CLI to express session trunking addresses. Chuck Lever made some good points around not using multiple hostnames: >>>> >>>> ---- From Chuck: ---- >>>> - client admins can specify arbitrary hostnames on the command line; hostnames >>>> for instance that correspond to some other server. >>>> >>>> - network conditions can change at anytime, making >>>> the original set of trunks lop-sided, or some trunks >>>> may become unreachable. What if the server reboots >>>> with new i/f's or with one or more removed? The >>>> client would likely have to remount in these cases >>>> to adapt to network configuration changes. >>>> >>>> - multiple hostnames could be nailed into >>>> /etc/fstab on potentially hundreds of clients. When >>>> server or network configuration changes, there would >>>> have to be a manual change on all these clients. >>>> ---------- >>>> >>>> What do you think? Should we keep the multiple hostname CLI as one method of expressing session trunking addresses? >>> I would think so... >> >> I don't believe a mount CLI is an obvious good choice. >> >> The client and server should provide some indication >> to each other that session trunking is supported. The >> server should provide the proper configuration >> parameters, which can change even while a client has >> mounted the server. >> >> That's why I favor having the client perform a >> GETATTR(fs_locations) on the server's pseudofs, via >> which the server provides the correct addresses to >> use. The client can poll for changes in the address >> list on a regular basis. >> >> Please, let's automate this instead of having to >> nail one more wonky feature into the mount CLI? > I guess I'm indifferent either way... but automation > is always a good thing... It seems like it would be easier on admins to set this up once on the server, rather than needing to configure the mount across all of their clients. Anna > > steved. > > -- > To unsubscribe from this list: send the line "unsubscribe linux-nfs" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html >