Re: [nfsv4] 4.0 trunking

[Chuck Lever <[e-mail]>]

> On Sep 30, 2016, at 4:52 PM, J. Bruce Fields <[e-mail]> wrote:
> 
> On Fri, Sep 30, 2016 at 04:25:00PM -0400, Andy Adamson wrote:
>> Chuck Lever and I are writing the IETF spec describing the use of
>> fs_locations/fs_locations_info for client multipath discovery for
>> NFSv4.1 non-pNFS or MDS server trunking. Do you think we should bother
>> with the NFSv4.0 (clientID trunking) case?
> 
> My feeling is that the problems we saw with 4.0 trunking are pretty easy
> to fix.  So don't take my complaints there as a reason to rule it out.
> 
> Like you, though, I'd rather ignore it.
> 
> The reason to do it would probably be to deliver this to people stuck on
> older OS's without 4.1 support, but those OS's are getting increasingly
> difficult to hack additional features into anyway.
> 
> If it were just me, I'd do the 4.1 case first.  Then if it looked like
> the same basic approach would cover 4.0 too--hey, why not.

I agree, 4.1 first, and 4.0 is worth looking into. Someone is bound to
read the trunking I-D and ask "why not 4.0" if we don't say something
about 4.0 in there. We don't have to spend a lot of time on it, but I
don't see why the RFC 7931 mechanism wouldn't permit clientid trunking
with 4.0.


> --b.
> 
>> 
>> -->Andy
>> 
>> On Tue, Sep 20, 2016 at 5:39 PM, J. Bruce Fields <[e-mail]> wrote:
>>> On Mon, Sep 12, 2016 at 12:59:05PM +0000, Adamson, Andy wrote:
>>>> IMHO we should not worry too much about NFSv4.0 trunking as NFSv4.1+ solves this issue. Trunking is simply one more reason to move from NFSv4.0 to NFSv4.1.
>>> 
>>> I tend to agree, but since it got implemented an was causing a real bug,
>>> it was hard to ignore....
>>> 
>>> After a patch (55b9df93ddd6 "NFSv4/v4.1: Verify the client owner id
>>> during trunking detection", if anyone cares) the damage seems restricted
>>> to the non-default "migration" case, making this less of a concern.
>>> 

--
Chuck Lever