From: Nikolaus Rath <Nikolaus@rath.org>
To: Rick Macklem <rmacklem@uoguelph.ca>
Cc: linux-nfs@vger.kernel.org, nfsv4@ietf.org,
"J. Bruce Fields" <bfields@fieldses.org>
Subject: Re: [nfsv4] NFS4 over VPN hangs when connecting > 2 clients
Date: Tue, 20 Mar 2012 09:29:57 -0400 [thread overview]
Message-ID: <4F688655.1090703@rath.org> (raw)
In-Reply-To: <716104306.1267694.1332195933869.JavaMail.root@erie.cs.uoguelph.ca>
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. 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.
Best,
-Nikolaus
--
»Time flies like an arrow, fruit flies like a Banana.«
PGP fingerprint: 5B93 61F8 4EA2 E279 ABF6 02CF A9AD B7F8 AE4E 425C
next prev parent reply other threads:[~2012-03-20 13:29 UTC|newest]
Thread overview: 46+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-03-11 1:34 NFS4 over VPN hangs when connecting > 2 clients Nikolaus Rath
2012-03-12 16:20 ` Nikolaus Rath
2012-03-12 19:31 ` J. Bruce Fields
2012-03-12 19:45 ` Nikolaus Rath
2012-03-12 20:15 ` J. Bruce Fields
2012-03-12 20:30 ` Nikolaus Rath
2012-03-12 20:42 ` J. Bruce Fields
2012-03-12 20:49 ` Chuck Lever
2012-03-12 21:04 ` J. Bruce Fields
2012-03-12 21:14 ` Chuck Lever
2012-03-12 21:27 ` J. Bruce Fields
2012-03-19 16:28 ` J. Bruce Fields
2012-03-19 16:44 ` [nfsv4] " Rick Macklem
2012-03-19 17:06 ` Rick Macklem
2012-03-19 17:36 ` J. Bruce Fields
2012-03-19 17:47 ` Chuck Lever
2012-03-19 18:24 ` Myklebust, Trond
2012-03-19 18:27 ` J. Bruce Fields
2012-03-19 18:29 ` Chuck Lever
2012-03-19 18:39 ` J. Bruce Fields
2012-03-19 18:42 ` Chuck Lever
2012-03-19 18:54 ` J. Bruce Fields
2012-03-19 19:00 ` Chuck Lever
2012-03-19 19:08 ` J. Bruce Fields
2012-03-19 18:43 ` Nikolaus Rath
2012-03-19 22:25 ` Rick Macklem
2012-03-20 13:29 ` Nikolaus Rath [this message]
2012-03-20 13:55 ` Myklebust, Trond
2012-03-20 14:36 ` Nikolaus Rath
2012-03-20 16:49 ` Myklebust, Trond
2012-03-20 14:01 ` Chuck Lever
2012-03-20 14:38 ` Nikolaus Rath
2012-03-20 15:53 ` Chuck Lever
2012-03-19 18:51 ` Nikolaus Rath
2012-03-19 18:56 ` J. Bruce Fields
2012-03-19 22:31 ` Rick Macklem
2012-03-19 18:26 ` Myklebust, Trond
2012-03-12 21:24 ` Nikolaus Rath
2012-03-12 21:27 ` Chuck Lever
2012-03-12 21:38 ` Nikolaus Rath
2012-03-12 21:46 ` Chuck Lever
2012-03-12 21:54 ` Chuck Lever
2012-03-12 21:54 ` Nikolaus Rath
2012-03-12 21:57 ` Myklebust, Trond
2012-03-13 13:23 ` Nikolaus Rath
2012-03-13 14:50 ` Myklebust, Trond
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4F688655.1090703@rath.org \
--to=nikolaus@rath.org \
--cc=bfields@fieldses.org \
--cc=linux-nfs@vger.kernel.org \
--cc=nfsv4@ietf.org \
--cc=rmacklem@uoguelph.ca \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox