On 01/21/2010 02:57 PM, J. Bruce Fields wrote:
On Thu, Jan 21, 2010 at 02:37:58PM -0500, Chuck Lever wrote:
On 01/21/2010 02:15 PM, J. Bruce Fields wrote:
On Wed, Jan 20, 2010 at 10:36:36AM -0500, Chuck Lever wrote:
For the record, we looked at Solaris behavior yesterday. With bi-family
servers, its mount command tries IPv6 first, but appears smart enough to
fall back to IPv4. One thing we haven't tried is to see how difficult it
would be to fix the real problem by adding proper protocol family
negotiation to our own mount command.
Sorry, I probably just haven't been following: what's "proper protocol
family negotiation"? I thought the only ways to negotiate were either
rpcbind (v2, v3) or trial and error (v4)?
In TI-RPC parlance, a "protocol" is the transport protocol (UDP, for
example), and a "protocol family" is the address family ("inet6", for
example). A netid represents a particular combination of the two: the
netid "udp6" represents UDP over "inet6".
The "protocol family" is really the value that is passed to socket(2).
This call generally takes PF_INET or something like that as its first
argument. All of the PF_FOO thingies have the same integer value as
their AF_FOO counterparts. For TI-RPC, we have "inet" and "inet6",
which are strings that match up with the AF_FOO and PF_FOO names.
rpcb_getaddr(3t) is designed to use the rpcbind protocol to determine
the address and transport to use when contacting a remote service. Our
mount command has its own negotiation mechanism that is a superset of
rpcbind calls, in addition to having a faster timeout than
rpcb_getaddr(3t).
What does "is a superset of rpcbind calls" mean?
rpcb_getaddr(3t) performs a single specific rpcbind query with a long
fixed timeout. mount.nfs uses several rpcbind queries, in a particular
order, to identify which NFS-related services are available. mount.nfs
uses individual queries rather than a single DUMPALL in order to enable
firewalls to detect which ports should be opened.
I still don't
understand what the proper protocol family negotiation is: what actually
happens on the wire?
If a particular RPC service (including rpcbind) cannot be contacted via
"inet6," and the server has an "inet" address listed in DNS, then
mount.nfs should be smart enough to try the mount request via the "inet"
address too. This is in addition to support for rpcbind queries that
can return a netid, which would include information about which protocol
family to use).
Currently our mount.nfs command fails if the target server has at least
one IPv6 address listed in DNS in addition to an IPv4 address, but does
not support NFS/IPv6.
For NFSv4, a server that has an IPv6 address but does not support
NFS/IPv6 will refuse connection to port 2049 over IPv6. In that case,
mount.nfs should tell the kernel to retry the mount with the server's
IPv4 address, if it has one.
For NFSv3, a server that has an IPv6 address, but does not support
NFS/IPv6, will not register any inet6 netids in its rpcbind database.
Thus the mount.nfs command has to be smart enough to retry
PROGNOTREGISTERED results with the server's IPv4 address, if it has one.
If the server has an IPv6 address, but is running portmap instead of
rpcbind, the initial rpcbind query connection will be refused (portmap
does not set up an IPv6 listener). In that case, the mount request
should be retried with the server's IPv4 address, if it has one.
Note that in any of these cases, if an NFS server does not have any IPv6
addresses listed in DNS, then behavior should be the same as before.
--
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
