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