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).
Until now, mount.nfs hasn't needed to negotiate the protocol family in
addition to the NFS and mount versions and transports. It always
assumed "inet" (or AF_INET, or PF_INET), and until recently, used only
rpcbind protocol version 2.
--
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
