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? I still don't
understand what the proper protocol family negotiation is: what actually
happens on the wire?
--b.
>
> 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.
--
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
