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(-)
>
next prev parent 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.