Re: [PATCH Version 3 0/2] Add multihostname support for NFSv4.1,2

[Anna Schumaker <Anna.Schumaker@netapp.com>]

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 <SteveD@redhat.com> 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 majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>