From: Ben Greear <greearb@candelatech.com>
To: Chuck Lever <chuck.lever@oracle.com>
Cc: linux-nfs@vger.kernel.org, Patrick McHardy <kaber@trash.net>
Subject: Re: PATCH: Support binding to a local IPv4 address when mounting a server.
Date: Fri, 23 Jan 2009 09:39:21 -0800 [thread overview]
Message-ID: <497A00C9.4010907@candelatech.com> (raw)
In-Reply-To: <65D69956-DB67-43A7-9101-9AFB7EC55A9F@oracle.com>
Chuck Lever wrote:
>> Why not clientaddr? That is already used for NFS version 4, and it works
>> just fine for version 3 as well. I can't think of any reason to have
>> a new variable.
>
> That may make sense for NFSv2/v3, but nfs(5) documents the clientaddr
> specifically as the client's NFSv4 callback server address. Is there
> ever a case where we want to specify a NFSv4 callback address that's
> different from the source address of your NFSv4 forward channel? Are we
> sure these will always be the same?
>
> Conversely, do we always want to limit our NFSv4 traffic to a single
> bind address when clientaddr= is specified?
>
> IMO the coding and documentation overhead for reusing clientaddr would
> be the same or greater than creating a new mount option, and the result
> would be more confusing. These two options do different things. I'd be
> interested to hear opinions from others on the list.
>
> "bindaddr=" might be more clear than "localaddr=". I checked Solaris
> 10, but it doesn't seem to have a similar capability. So, no guidance
> there...
Either way is fine with me. I'll change it to be bindaddr unless
I hear another opinion.
Thanks,
Ben
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
next prev parent reply other threads:[~2009-01-23 17:39 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-01-22 1:01 PATCH: Support binding to a local IPv4 address when mounting a server Ben Greear
2009-01-22 2:38 ` Chuck Lever
2009-01-22 5:35 ` Ben Greear
2009-01-22 17:06 ` Chuck Lever
2009-01-22 17:31 ` Ben Greear
2009-01-23 17:18 ` Chuck Lever
2009-01-23 17:39 ` Ben Greear [this message]
2009-02-21 7:43 ` Ben Greear
2009-02-21 17:16 ` Trond Myklebust
2009-02-21 22:09 ` Chuck Lever
2009-02-22 5:52 ` Ben Greear
2009-02-22 19:09 ` Trond Myklebust
[not found] ` <1235329791.7331.75.camel-rJ7iovZKK19ZJLDQqaL3InhyD016LWXt@public.gmane.org>
2009-02-22 20:29 ` Chuck Lever
2009-02-22 22:01 ` Trond Myklebust
2009-02-22 23:17 ` Ben Greear
2009-02-22 23:41 ` Trond Myklebust
[not found] ` <1235346094.7331.111.camel-rJ7iovZKK19ZJLDQqaL3InhyD016LWXt@public.gmane.org>
2009-02-22 23:45 ` Ben Greear
2009-02-22 6:24 ` Ben Greear
2009-02-22 20:01 ` Chuck Lever
2009-02-22 7:05 ` Ben Greear
-- strict thread matches above, loose matches on Subject: below --
2009-02-21 18:18 Ben Greear
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=497A00C9.4010907@candelatech.com \
--to=greearb@candelatech.com \
--cc=chuck.lever@oracle.com \
--cc=kaber@trash.net \
--cc=linux-nfs@vger.kernel.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.