> On Feb 19, 2016, at 10:01 AM, J. Bruce Fields <bfields@xxxxxxxxxxxx> 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 -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
