On 03/19/2012 02:39 PM, J. Bruce Fields wrote:
> On Mon, Mar 19, 2012 at 02:29:46PM -0400, Chuck Lever wrote:
>>
>> On Mar 19, 2012, at 2:27 PM, J. Bruce Fields wrote:
>>
>>> On Mon, Mar 19, 2012 at 01:47:14PM -0400, Chuck Lever wrote:
>>>>
>>>> On Mar 19, 2012, at 1:36 PM, J. Bruce Fields wrote:
>>>>> Well, sure, but all I'm proposing here is returning NFS4ERR_INUSE in the
>>>>> case where we get setclientid's with the same client-provided id.
>>>>> There'd be no change of behavior in the case of multiple clients sharing
>>>>> an IP (which is fine, of course).
>>>>
>>>> The migration draft proposes that clients use the same nfs_client_id4 string for all of a server's IP addresses. Would a server then be obliged to return NFS4ERR_CLID_IN_USE if a client attempts a SETCLIENTID with the same boot verifier and nfs_client_id4 on more than one IP address for the same server?
>>>
>>> That's also not this case, sorry, this time with all the conditions:
>>>
>>> - if the nfs_client_id4 is the same, and
>>> - if the flavor is auth_sys, and
>>> - if the client IP address is different,
>>> - then return NFS4ERR_INUSE.
>>
>> This still breaks for multi-homed servers and UCS clients. The client IP address can be different depending on what server IP address the client is accessing, but all the other parameters are the same.
>
> OK. So probably there's nothing we can do to help here.
>
> As a bandaid maybe a rate-limited log message ("clientid X now in use
> from IP Y") might help debug these things....
Since you guys keep Cc'ing me, I'll chime in with a rather naive
suggestion: if all that's required is a unique id for every client, why
not use the MAC of the first network interface, independent of it being
used for communication with the server?
Best,
-Nikolaus
--
»Time flies like an arrow, fruit flies like a Banana.«
PGP fingerprint: 5B93 61F8 4EA2 E279 ABF6 02CF A9AD B7F8 AE4E 425C
--
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
