Re: "Re: [PATCH RFC Version 1 0/6] Request for Comment: NFS4.1 Session Trunking"

[Chuck Lever <chuck.lever@oracle.com>]

> On Feb 19, 2016, at 10:01 AM, J. Bruce Fields <bfields@fieldses.org> wrote:
> 
> On Thu, Feb 18, 2016 at 04:29:46PM -0500, Chuck Lever wrote:
>> True; there's a reason I never got to implementing
>> fs_locations_info on the Linux server for FedFS. There
>> are sticky problems around the mountd upcall that is
>> used to communicate this information to the kernel,
>> for example.
>> 
>> However, I don't agree that this is a good reason to
>> go with multiple hostnames on the mount command line.
>> I like Andy's plan to keep this CLI change out of the
>> long term upstream code, but continue to use it for
>> testing.
> 
> Even if we get an fs_locations_info-based solution to the point where
> it's the best default, don't you think we'll still want some kind of
> manual override on the client?

Perhaps! But that doesn't mean multiple hostnames in
particular is the right CLI.

Suppose a "notrunk" mount option was added. The client
would ignore the server's fs_locations_info and use
only the hostname provided on the command line.

Another idea is to provide a blacklist as a mount
option. "notrunk=IPv4,IPv4,[IPv6],[IPv6]"


> The decision here has to do with the path between client and server,
> and the server may not always be in the best position to make that
> decision.

The server is not making any decision about the path.
It simply provides a list of its i/f's.

The client may choose to use one or more of the IP
addresses on the server's list. The client is not
required to use all the server's IP addresses, and
it does have the ability to determine that some
addresses are not reachable (eg IPv6 addresses,
private networks, and so on), though that may take
a timeout or two.

But back to the client CLI:

With multiple hostnames, client admins can specify
arbitrary hostnames on the command line; hostnames
for instance that correspond to some other server.

And, 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.

Note that 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.


--
Chuck Lever