On May 26, 2009, at 12:49 PM, Jeff Layton wrote:
On Tue, 26 May 2009 11:24:05 -0400
Chuck Lever <chuck.lever@xxxxxxxxxx> wrote:
Hi Jeff-
On May 26, 2009, at 11:15 AM, Jeff Layton wrote:
Add 2 new options to rpc.nfsd -- -4 and -6. -4 makes it an IPv4-only
server, and -6 makes it IPv6-only. Restructure the -H option so that
if the address appears to be or resolves to an IPv4 address, that
IPv6 is disabled. Ditto if it resolves to an IPv6 address.
The new rpc.statd doesn't have a "-4" or "-6" option. It looks in /
etc/netconfig to start only the visible transports. I was suggesting
that rpc.nfsd use /etc/netconfig _instead_ of having a -4/-6 command-
line option.
Just a thought.
I don't feel strongly about it either way. It seems reasonable that
someone might want to disable ipv4 or ipv6 without changing
/etc/netconfig. This also has some parity with the -T and -U options
too...
It would be good however to have nfsd and statd share options and
behavior here, so I think we should implement the same convention for
both. Do you think it would be better to remove -4/-6 from nfsd, or
add
those options to the new statd?
My sense is statd is a kind of set-it-and-forget-it kind of thing. It
doesn't have a lockd_up() kind of API that, for example, mount.nfs or
rpc.nfsd can invoke, to ensure that it's listening for a particular
protocol family or protocol (eventually mount.nfs could ping it via
IPv6 when mounting an IPv6 server, but it doesn't do that today). So
it starts everything to cover all the bases. That can change if
someone has a cogent argument!
rpc.nfsd is another kind of beast, as it's starting kernel services,
not a user space listener. Even given rpc.nfsd's past of allowing -T
and -U, it's hard to say whether users will want the flexibility of
enabling IPv6 or IPv4, or whether they will want whatever families are
supported with the option of supporting UDP or TCP on both families.
If there's a way to make it all automatic, that might be the best
choice.
But I'd hesitate to introduce -4 and -6 if there's a realistic
possibility that we may not want or need that kind of flexibility in
the end. Maybe we can go without for now, and add those options later
if needed?
Plus, do we want a "don't ever use IPv4" or "IPv6" kind of setting, or
just a "please start IPv4" or "IPv6" setting? Does -6 exclude IPv4
and vice versa? What should it mean when neither are present?
Once we have everything done, we might look back and say we definitely
need these options on all the user space components, and at that point
we'd have a clear idea how to make the options behave consistently for
all of the pieces. I guess this is an argument for leaving these
options off until we have a better sense of what is needed.
--
Chuck Lever
chuck[dot]lever[at]oracle[dot]com
--
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
