On Fri, Apr 29, 2016 at 11:24:30AM -0400, 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? 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. -- 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
