Return-Path: Received: from mx144.netapp.com ([216.240.21.25]:41688 "EHLO mx144.netapp.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752498AbcD2Tjn (ORCPT ); Fri, 29 Apr 2016 15:39:43 -0400 From: Anna Schumaker Subject: Re: [PATCH Version 3 0/2] Add multihostname support for NFSv4.1,2 To: "J. Bruce Fields" , 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> <20160429180532.GB6035@fieldses.org> CC: Steve Dickson , "Adamson, Andy" , Trond Myklebust , Linux NFS Mailing List Message-ID: Date: Fri, 29 Apr 2016 15:39:35 -0400 MIME-Version: 1.0 In-Reply-To: <20160429180532.GB6035@fieldses.org> Content-Type: text/plain; charset="utf-8" Sender: linux-nfs-owner@vger.kernel.org List-ID: On 04/29/2016 02:05 PM, J. Bruce Fields wrote: > On Fri, Apr 29, 2016 at 11:24:30AM -0400, 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? > > Yeah, I guess that makes sense. > > My worries from the previous thread were that the fs_locations and > fs_locations_info don't *really* give enough information to guarantee > that trunking will be an improvement. > > But I'd guess those cases aren't common (maybe fs_locations use isn't > even that common). Still, might want a way to opt out. > > Maybe it would be worth documenting what the automatic probing does so > that servers know how to influence it if desired. Would it make sense to add configuration options to /etc/exports to set up how the server handles this? Anna > > --b. > -- > 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 >