On 03/20/2012 10:01 AM, Chuck Lever wrote:
>
>
> Sent from my iPad
>
> On Mar 20, 2012, at 9:29 AM, Nikolaus Rath <Nikolaus@xxxxxxxx> wrote:
>
>> On 03/19/2012 06:25 PM, Rick Macklem wrote:
>>> Nikolaus Rath wrote:
>>>> 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?
>>>>
>>> I think this works fairly well for "real hardware", but I'm not so sure
>>> about clients running in VMs. (I don't really know how the VMs assign
>>> MAC addresses to their fake net interfaces and what uniqueness guarantees
>>> those have. I remember the old freebie VMware client for Windows just
>>> had a config file that assigned the MAC. I bet half the installations
>>> on the planet had the same MAC as the default config file:-)
>>
>> But as I understand, the clientid doesn't have to globally unique, just
>> unique for the given NFS server.
>
> Global uniqueness is required to support Transparent State Migration.
>
>> I think if you have two virtual
>> machines with the same MAC connecting to the same NFS server, you have
>> different problems anyway.
>>
>>
>>> ps: Also, although it's not very relevant, getting the MAC address of
>>> the first ethernet interface isn't easy in FreeBSD. I have no idea
>>> if the same is true of Linux. (I'd also be worried that "first"
>>> might not be fixed?)
>>
>> It doesn't need to be the same interface all the time, I just meant the
>> first as in not a specific one.
>
> The nfs_client_id4 string must not change across a reboot. Otherwise the server won't be able to figure out which open and lock state to discard when the client reboots.
But I thought that at the moment one of the client's ips is used for the
clientid? That's certainly changes regurlarly for DHCP or multi-homed
clients.
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
