On Jan 30, 2009, at Jan 30, 2009, 5:49 PM, Trond Myklebust wrote:
On Fri, 2009-01-30 at 17:27 -0500, Chuck Lever wrote:
On Jan 30, 2009, at Jan 30, 2009, 4:59 PM, Trond Myklebust wrote:
On Fri, 2009-01-30 at 16:30 -0500, Chuck Lever wrote:
If so, it sounds to me as if
we _must_ have lockd and the callback server set up IPv6 sockets
whenever they are available.
That's what the code does now. The problem is exactly what does
"whenever they are available" mean?
Are you suggesting we shouldn't ever fall back to AF_INET? (I'm OK
with that answer, but would like a discussion). This means that
if I
try an IPv4 mount on a system built with an IPv6 module, but the
module is unloadable, all mounts (even IPv4) fail outright.
Apparently a lot of folks blacklist their IPv6 modules.
I'd rather advocate that we try to use AF_INET6 at service set up
time,
then fall back on AF_INET only if the former isn't available. I'm
not
sure that we should allow the user to change the service once it has
been set up, since it would appear that would force you to close the
current socket, and then reopen a new one of a different type.
That's
both racy and constitutes an interruption of service.
The listeners will pin the ipv6 module while they exist. At some
point, if the listeners are stopped, the ipv6 module can be
blacklisted. Subsequent NFS mounts will fail at that point, but a
reboot (or perhaps unloading the lockd and nfs modules) will make it
right again.
Seems like a good argument for separate listeners.
My point was that you might lose the IPv4 port, however that's moot
when
you can set up an IPV6_V6ONLY socket. Note that this appears to be the
technique favoured by ssh.
I've been thinking more about this, and having separate listeners has
some appeal. At least as far as I've thought about it, separate
listeners simplify the cases where the kernel RPC services have to
adapt at run-time to what kind of networking is available in the kernel.
inet6 netids do not support mapped IPv4, as far as I can tell, so if
we have an AF_INET listener and an IPV6ONLY AF_INET6 listener, they
will get separate traffic streams. It means we avoid entirely having
to compare AF_INET addresses to mapped IPv4 AF_INET6 addresses during
NFSv4 and NLM callbacks. And, we can always start an AF_INET
listener, and start AF_INET6 listeners only if IPv6 support is
available in the kernel.
This looks more like TI-RPC's IPv6 support.
That said, I think I'd prefer the single socket solution that we have
now. It would certainly make life easier for migration events, and
possibly pnfs. In neither of these cases do you know at mount time
what
kind of callback service you will need later, so setting up an IPv4-
only
service might turn out wrong.
I'm not familiar enough with the issues around migration to comment.
Do you have an example of a migration event that might be problematic
with separate listeners?
--
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
