On 29/04/16 11:24, Chuck Lever wrote: > >> On Apr 29, 2016, at 10:46 AM, Steve Dickson <SteveD@xxxxxxxxxx> 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. -- 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
