linux-nfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Steve Dickson <SteveD@redhat.com>
To: "Adamson, Andy" <William.Adamson@netapp.com>,
	"trond.myklebust@primarydata.com"
	<trond.myklebust@primarydata.com>
Cc: "linux-nfs@vger.kernel.org" <linux-nfs@vger.kernel.org>
Subject: Re: [PATCH Version 3 0/2] Add multihostname support for NFSv4.1,2
Date: Fri, 29 Apr 2016 10:46:22 -0400	[thread overview]
Message-ID: <572373BE.4000201@RedHat.com> (raw)
In-Reply-To: <1461940027554.14958@netapp.com>



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... Just to put some context into this... We are talking
about:

mount -o v4.1 server1,server2,server3:/export /mnt

server1 would be tried, if that fails server2 would be tried?

steved.

  reply	other threads:[~2016-04-29 14:46 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-04-27 15:36 [PATCH Version 3 0/2] Add multihostname support for NFSv4.1,2 andros
2016-04-27 15:36 ` [PATCH Version 3 1/2] NFS parse NFSv4 multiple hostnames andros
2016-04-27 15:36 ` [PATCH Version 3 2/2] NFS add multiaddr mount option andros
2016-04-29 14:12 ` [PATCH Version 3 0/2] Add multihostname support for NFSv4.1,2 Steve Dickson
2016-04-29 14:27   ` Adamson, Andy
2016-04-29 14:46     ` Steve Dickson [this message]
2016-04-29 15:09       ` Adamson, Andy
2016-04-29 15:24       ` Chuck Lever
2016-04-29 15:50         ` Steve Dickson
2016-04-29 15:53           ` Anna Schumaker
2016-04-29 18:05         ` J. Bruce Fields
2016-04-29 19:39           ` Anna Schumaker
2016-04-29 20:03             ` J. Bruce Fields

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=572373BE.4000201@RedHat.com \
    --to=steved@redhat.com \
    --cc=William.Adamson@netapp.com \
    --cc=linux-nfs@vger.kernel.org \
    --cc=trond.myklebust@primarydata.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).