From: Andy Adamson <[email protected]>
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.
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(-)
--
1.8.3.1
From: Andy Adamson <[email protected]>
Signed-off-by: Andy Adamson <[email protected]>
---
utils/mount/stropts.c | 60 +++++++++++++++++++++++++++++++++++++++++++++++++++
1 file changed, 60 insertions(+)
diff --git a/utils/mount/stropts.c b/utils/mount/stropts.c
index 75646f6..334638b 100644
--- a/utils/mount/stropts.c
+++ b/utils/mount/stropts.c
@@ -365,6 +365,59 @@ static int nfs_set_version(struct nfsmount_info *mi)
return 1;
}
+/**
+ * Append any multiaddrs to the mount options to be used for session trunking.
+ *
+ * Do not fail the mount due to multiaddr processing.
+ *
+ * @multinames: comma separated multi-host list. NOTE: does not include the
+ * first host name which is used as the mount host.
+ */
+static void
+nfs_append_multiaddr_option(char *multinames, struct mount_options *options,
+ int family)
+{
+ struct addrinfo hint = {
+ .ai_protocol = (int)IPPROTO_UDP,
+ .ai_family = family,
+ };
+ char *comma, *name;
+ struct addrinfo *temp;
+ int error;
+
+ if (!multinames)
+ return;
+
+ name = multinames;
+ comma = strchr(name, ',');
+ while (name != NULL) {
+ if (comma != NULL)
+ *comma = '\0';
+
+ error = getaddrinfo(name, NULL, &hint, &temp);
+ if (error != 0) {
+ nfs_error(_("%s: Failed to resolve server %s: %s"),
+ progname, name, gai_strerror(error));
+ continue;
+ }
+
+ if (!nfs_append_generic_address_option(temp->ai_addr,
+ temp->ai_addrlen,
+ "multiaddr", options)) {
+ nfs_error(_("%s: Failed to append multiaddr %s"),
+ progname, name);
+ continue;
+ }
+ if (comma == NULL)
+ name = NULL;
+ else {
+ name = comma +1;
+ comma = strchr(name, ',');
+ }
+ }
+ return;
+}
+
/*
* Set up mandatory non-version specific NFS mount options.
*
@@ -403,6 +456,13 @@ static int nfs_validate_options(struct nfsmount_info *mi)
mi->address->ai_addrlen, mi->options))
return 0;
+ if ((mi->version.major == 4 && mi->version.minor > 0))
+ nfs_append_multiaddr_option(mi->multinames, mi->options,
+ family);
+ else
+ if (mi->multinames)
+ nfs_error(_("%s: warning: multiple hostnames not"
+ " supported"),progname);
return 1;
}
--
1.8.3.1
From: Andy Adamson <[email protected]>
For NFSv4.x mounts
Signed-off-by: Andy Adamson <[email protected]>
---
utils/mount/parse_dev.c | 30 ++++++++++++++++++++----------
utils/mount/parse_dev.h | 2 +-
utils/mount/stropts.c | 3 ++-
utils/mount/utils.c | 2 +-
4 files changed, 24 insertions(+), 13 deletions(-)
diff --git a/utils/mount/parse_dev.c b/utils/mount/parse_dev.c
index 0d3bcb9..c5d2215 100644
--- a/utils/mount/parse_dev.c
+++ b/utils/mount/parse_dev.c
@@ -79,10 +79,10 @@ static int nfs_pdn_missing_brace_err(void)
/*
* Standard hostname:path format
*/
-static int nfs_parse_simple_hostname(const char *dev,
- char **hostname, char **pathname)
+static int nfs_parse_simple_hostname(const char *dev, char **hostname,
+ char **multinames, char **pathname)
{
- size_t host_len, path_len;
+ size_t host_len, multi_len = 0, path_len;
char *colon, *comma;
/* Must have a colon */
@@ -96,13 +96,15 @@ static int nfs_parse_simple_hostname(const char *dev,
return nfs_pdn_hostname_too_long_err();
/* If there's a comma before the colon, take only the
- * first name in list */
+ * first name in list as the hostname, the rest get stored in
+ * the multinames. Note that NFS_MAXHOSTNAME limits the number
+ * of multinames */
comma = strchr(dev, ',');
if (comma != NULL) {
*comma = '\0';
host_len = comma - dev;
- nfs_error(_("%s: warning: multiple hostnames not supported"),
- progname);
+ comma++;
+ multi_len = colon - comma;
} else
colon++;
@@ -115,6 +117,11 @@ static int nfs_parse_simple_hostname(const char *dev,
if (*hostname == NULL)
return nfs_pdn_nomem_err();
}
+ if (multinames && multi_len != 0) {
+ *multinames = strndup(comma, multi_len);
+ if (*multinames == NULL)
+ return nfs_pdn_nomem_err();
+ }
if (pathname) {
*pathname = strndup(colon, path_len);
if (*pathname == NULL) {
@@ -196,11 +203,13 @@ static int nfs_parse_nfs_url(__attribute__((unused)) const char *dev,
* nfs_parse_devname - Determine the server's hostname by looking at "devname".
* @devname: pointer to mounted device name (first argument of mount command)
* @hostname: OUT: pointer to server's hostname
+ * @multinames: OUT: pointer to comma separated multiple server interface names
* @pathname: OUT: pointer to export path on server
*
* Returns 1 if succesful, or zero if some error occurred. On success,
- * @hostname and @pathname point to dynamically allocated buffers containing
- * the hostname of the server and the export pathname (both '\0'-terminated).
+ * @hostname, @multinames, and @pathname point to dynamically allocated
+ * buffers containing the hostname of the server, other multiple server
+ * interfaces, and the export pathname (all '\0'-terminated).
*
* @hostname or @pathname may be NULL if caller doesn't want a copy of those
* parts of @devname.
@@ -208,7 +217,7 @@ static int nfs_parse_nfs_url(__attribute__((unused)) const char *dev,
* Note that this will not work if @devname is a wide-character string.
*/
int nfs_parse_devname(const char *devname,
- char **hostname, char **pathname)
+ char **hostname, char **multinames, char **pathname)
{
char *dev;
int result;
@@ -225,7 +234,8 @@ int nfs_parse_devname(const char *devname,
else if (strncmp(dev, "nfs://", 6) == 0)
result = nfs_parse_nfs_url(dev, hostname, pathname);
else
- result = nfs_parse_simple_hostname(dev, hostname, pathname);
+ result = nfs_parse_simple_hostname(dev, hostname, multinames,
+ pathname);
free(dev);
return result;
diff --git a/utils/mount/parse_dev.h b/utils/mount/parse_dev.h
index f9857bc..ef663f8 100644
--- a/utils/mount/parse_dev.h
+++ b/utils/mount/parse_dev.h
@@ -23,6 +23,6 @@
#ifndef __NFS_UTILS_PARSE_DEV_HEADER
#define __NFS_UTILS_PARSE_DEV_HEADER
-extern int nfs_parse_devname(const char *, char **, char **);
+extern int nfs_parse_devname(const char *, char **, char **, char **);
#endif /* __NFS_UTILS_PARSE_DEV */
diff --git a/utils/mount/stropts.c b/utils/mount/stropts.c
index 86829a9..75646f6 100644
--- a/utils/mount/stropts.c
+++ b/utils/mount/stropts.c
@@ -83,6 +83,7 @@ struct nfsmount_info {
*node, /* mounted-on dir */
*type; /* "nfs" or "nfs4" */
char *hostname; /* server's hostname */
+ char *multinames; /* more server interfaces */
struct addrinfo *address; /* server's addresses */
struct mount_options *options; /* parsed mount options */
@@ -377,7 +378,7 @@ static int nfs_validate_options(struct nfsmount_info *mi)
sa_family_t family;
int error;
- if (!nfs_parse_devname(mi->spec, &mi->hostname, NULL))
+ if (!nfs_parse_devname(mi->spec, &mi->hostname, &mi->multinames, NULL))
return 0;
if (!nfs_nfs_proto_family(mi->options, &family))
diff --git a/utils/mount/utils.c b/utils/mount/utils.c
index 92662ed..2b6ee74 100644
--- a/utils/mount/utils.c
+++ b/utils/mount/utils.c
@@ -159,7 +159,7 @@ int nfs_umount23(const char *devname, char *string)
struct mount_options *options;
int result = EX_FAIL;
- if (!nfs_parse_devname(devname, &hostname, &dirname))
+ if (!nfs_parse_devname(devname, &hostname, NULL, &dirname))
return EX_USAGE;
options = po_split(string);
--
1.8.3.1
Hey Andy,
On 04/27/2016 11:36 AM, [email protected] wrote:
> From: Andy Adamson <[email protected]>
>
> 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(-)
>
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 <[email protected]>
Sent: Friday, April 29, 2016 10:12 AM
To: Adamson, Andy; [email protected]
Cc: [email protected]
Subject: Re: [PATCH Version 3 0/2] Add multihostname support for NFSv4.1,2
Hey Andy,
On 04/27/2016 11:36 AM, [email protected] wrote:
> From: Andy Adamson <[email protected]>
>
> 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(-)
>
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.
> mount -o v4.1 server1,server2,server3:/export /mnt
>
> server1 would be tried, if that fails server2 would be tried?
That is not the way this feature was coded. Currently, server1 is tried. If server1 fails, the mount fails. If server1 succeeds then server2,server3.. are tried as session trunking addrs.
I can of course change this to the behavior you described.
-->Andy
________________________________________
From: Steve Dickson <[email protected]>
Sent: Friday, April 29, 2016 10:46 AM
To: Adamson, Andy; [email protected]
Cc: [email protected]
Subject: Re: [PATCH Version 3 0/2] Add multihostname support for NFSv4.1,2
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.
> On Apr 29, 2016, at 10:46 AM, Steve Dickson <[email protected]> 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?
> 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.
> --
> To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Chuck Lever
On 29/04/16 11:24, Chuck Lever wrote:
>
>> On Apr 29, 2016, at 10:46 AM, Steve Dickson <[email protected]> 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...
steved.
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 <[email protected]> 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 [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
On Fri, Apr 29, 2016 at 11:24:30AM -0400, Chuck Lever wrote:
>
> > On Apr 29, 2016, at 10:46 AM, Steve Dickson <[email protected]> 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.
--b.
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 <[email protected]> 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 [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
On Fri, Apr 29, 2016 at 03:39:35PM -0400, Anna Schumaker wrote:
> 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 <[email protected]> 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?
We have the "replicas=" option that'll allow you to set the fs_locations
list.
If we wanted a "turn off session trunking at the server" switch, that'd
need code. Maybe it would advertise a different minor identifier per
interface in that case? Or you could allow finer-grained configuration
of minor numbers from userspace if we wanted to. We could also
implement fs_locations_info, though it doesn't really seemed designed to
communicate this kind of information.
Not really knowing what people might want to do this, I'm inclined to
leave things as is and wait to see what's needed. "replicas=" is
probably good enough for now on the server side, and maybe some simple
switch on the client side would be useful.
--b.