linux-nfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Adamson, Andy" <William.Adamson@netapp.com>
To: Steve Dickson <SteveD@redhat.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 14:27:06 +0000	[thread overview]
Message-ID: <1461940027554.14958@netapp.com> (raw)
In-Reply-To: <57236BB6.50103@RedHat.com>

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?

-->Andy
________________________________________
From: Steve Dickson <SteveD@redhat.com>
Sent: Friday, April 29, 2016 10:12 AM
To: Adamson, Andy; trond.myklebust@primarydata.com
Cc: linux-nfs@vger.kernel.org
Subject: Re: [PATCH Version 3 0/2] Add multihostname support for NFSv4.1,2

Hey Andy,

On 04/27/2016 11:36 AM, andros@netapp.com wrote:
> From: Andy Adamson <andros@netapp.com>
>
> RFC patchset
>
> Main question: Do we want to use multiple hostnames on the mount command to
>    communicate the NFSv4.1 session trunking addresses, or only use (yet
>    to be coded) fs_locations_info?
>
> The multiple hostnames on the mount command are added to a new multiaddr
> option and passed to the kernel for consumption.
Should there be some type of man page update talking about his new option
and how to used it?

steved.

>
> This code requires the kernel "Version 3 NFSV4.1,2 session trunking"
> patch set.
>
> If we want to keep the multiple hostnames on the mount command method of
> expressing NFSv4.1 session trunking addresses, we should fix this:
>
> - v3 mounts with multiple hostnames succeeds but adds an mtab dev entry that
> omits the ":/<exported dir> and so prints a warning at umount.
> - need to update the manpage
>
> -->Andy
>
> Andy Adamson (2):
>   NFS parse NFSv4 multiple hostnames
>   NFS add multiaddr mount option
>
>  utils/mount/parse_dev.c | 30 +++++++++++++++--------
>  utils/mount/parse_dev.h |  2 +-
>  utils/mount/stropts.c   | 63 ++++++++++++++++++++++++++++++++++++++++++++++++-
>  utils/mount/utils.c     |  2 +-
>  4 files changed, 84 insertions(+), 13 deletions(-)
>

  reply	other threads:[~2016-04-29 14:27 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 [this message]
2016-04-29 14:46     ` Steve Dickson
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=1461940027554.14958@netapp.com \
    --to=william.adamson@netapp.com \
    --cc=SteveD@redhat.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).