Re: [PATCH 3/5] nfs-utils: query for remote port using rpcbind instead of getaddrinfo

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tue, 07 Apr 2009 15:43:39 -0400
Tom Talpey <tmtalpey@xxxxxxxxx> wrote:

> At 01:11 PM 4/7/2009, Jeff Layton wrote:
> >On Tue, 07 Apr 2009 12:27:49 -0400
> >Tom Talpey <tmtalpey@xxxxxxxxx> wrote:
> >
> >> At 12:02 PM 4/7/2009, Chuck Lever wrote:
> >> >
> >> >On Apr 7, 2009, at 11:25 AM, Jeff Layton wrote:
> >> >> +	/* Use standard NFS port for NFSv4 */
> >> >> +	if (program == 100003 && version == 4) {
> >> >> +		port = 2049;
> >> >> +		goto set_port;
> >> >> +	}
> >> >
> >> >I think this patch set looks pretty reasonable.  Here's my one  
> >> >remaining quibble.
> >> >
> >> >You can specify "port=" for nfs4 mounts, in which case we want to use  
> >> >that value here, too, I think.  It would be simpler overall if the  
> >> 
> >> *Must* use a port= specification. The 2049 definition is only true for
> >> NFSv4/TCP, as a counterexample the NFSv4/RDMA IANA binding is
> >> port 20049. So slamming the port to 2049 would break NFSv4/RDMA.
> >> 
> >
> >rpc.gssd doesn't seem to be rdma-enabled at this point. It only seems
> >to handle "tcp" and "udp" in the existing code.
> 
> Fair enough. But hardwiring 2049 for all transports is going to very
> problematic. What's the motivation for bypassing the rpcbind query
> altogether (that "goto set_port" skips over it)? Why not at least
> try the query first?
>
> >Does libtirpc handle RDMA properly? If so, this might not be too hard
> >to enable, but I'd probably rather see it in a follow on patchset (and
> >maybe by someone with more of a clue about RDMA than I currently have).
> 
> No, libtirpc doesn't have any RDMA support. But, there's no need for
> RDMA support in it - only NFS does RDMA, in practice, and currently
> that's just in-kernel.
> 
> My concern is simply that there be a way to specify, or discover a port
> that isn't 2049 here. If mount.nfs supports it, other nfs-utils should too.
> 

I forget which version is the cutoff, but newer kernels tell gssd which
port to use. That hardwiring is only for older kernels that don't send
the port in the upcall.

Could we try a short-timeout rpcbind call for those older kernels that
don't send the port? Sure. Is it worth it? I'm not as sure there.

I'd rather see these people just update their kernels so that this
isn't needed...

-- 
Jeff Layton <jlayton@xxxxxxxxxx>
--
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

[Index of Archives]     [Linux Filesystem Development]     [Linux USB Development]     [Linux Media Development]     [Video for Linux]     [Linux NILFS]     [Linux Audio Users]     [Yosemite Info]     [Linux SCSI]

  Powered by Linux