mount - unknown option rdma

James Lentini jlentini at netapp.com
Fri Feb 8 14:43:26 EST 2008



On Fri, 8 Feb 2008, Brent Callaghan wrote:

> 
> On Feb 8, 2008, at 8:46 AM, Chuck Lever wrote:
> 
> > Because RDMA is such a new feature, support for it was added to the C
> > string option parser, but not to the legacy binary API.  So for now,
> > you need to use the /sbin/mount.nfs subcommand *and* specify "-i" to
> > force passing mount options to the kernel via a C string.
> 
> Interesting: as I read it, the "rdma" option is required if you want 
> the client to use an rdma-based transport for the mount.

Correct.

> It implies that if you connect up a shiny new rdma network, you then 
> have to track down all the fstabs and automounter maps and edit in 
> the new rdma mount option to use it.
> 
> Wouldn't it be easier to have the NFS mount use rdma by default if 
> it's available, and fall back to "tcp" or "udp" if not ?
> 
> 	Brent

The issue is that RDMA support is required on both ends of the wire. 
The client may have an RDMA device installed but currently there is no 
way to programmatically determine that the server supports RDMA with 
attempting a connection (we don't yet register our rdma proto with 
rpcbind/portmapper). Even if RDMA is supported on both ends, there may 
not be an RDMA networking connecting them. For example, the client and 
server could each be on a separate InfiniBand network.


More information about the NFSv4 mailing list