Bug 886623

(In reply to comment #0)
> Description of problem:
> Automounting NFS via RDMA fails since it only probes with TCP/UDP: 

As far as I can tell libtirpc doesn't understand protocol rdma.

snip ...

> 
> - You can workaround this issue by setting MOUNT_WAIT="" to a high value,
> such as 300 in /etc/sysconfig/autofs as setting the MOUNT_WAIT parameter to
> 300 effectively disables the probing functionality described above since
> default_get_mount_wait is non-equal to -1.  

You could call it a workaround but that has been done specifically
for people that, for one reason or another, don't want availability
probing to be done. Note that setting MOUNT_WAIT to any value other
than -1 will prevent the probe from being done for simple mounts as
was previously the case. Setting it to 300 is probably not the best
for interactive response, 20 - 40 seconds (or less) is more sensible
I think.

Clearly this is one of those cases.

> 
> - It looks like this was introduced with
> autofs-5.0.6-reinstate-singleton-mount-probe.patch

Yes, which was done in response to changes in other areas (ie.
not autofs) which was causing long delays if a server was not
available. It was the only option I had to improve the situation.

Since, in user space, I can't seem to find a way to utilize the
rdma protocol for RPC we could add a check to not do any probing
at all when that mount option is given. That might not be entirely
straight forward either. I'll have another look around when I get
a chance.

Ian

Just ran into this myself.  MOUNT_WAIT works.

Created attachment 775658 [details]
Patch - dont probe rdma mounts

[root@hp-dl320g5-01 ~]# rpm -q autofs; uname -r
autofs-5.0.5-86.el6.x86_64
2.6.32-415.0.1.el6.x86_64
[root@hp-dl320g5-01 ~]# cat /proc/fs/nfsd/portlist
rdma 20049
udp 2049
tcp 2049
udp 2049
tcp 2049
[root@hp-dl320g5-01 ~]# automount -m file auto.nfs 2>/dev/null
systmp  -nobind,rw,rdma   127.0.0.1:/tmp
[root@hp-dl320g5-01 ~]# vim /etc/auto.master 
[root@hp-dl320g5-01 ~]# ls /nfsmp/systmp
ls: cannot access /nfsmp/systmp: No such file or directory
[root@hp-dl320g5-01 ~]# tail -n30 /var/log/messages 
Sep 16 22:47:03 hp-dl320g5-01 automount[9267]: mounted indirect on /net with timeout 300, freq 75 seconds
Sep 16 22:47:03 hp-dl320g5-01 automount[9267]: st_ready: st_ready(): state = 0 path /net
Sep 16 22:47:55 hp-dl320g5-01 automount[9267]: handle_packet: type = 3
Sep 16 22:47:55 hp-dl320g5-01 automount[9267]: handle_packet_missing_indirect: token 1, name systmp, request pid 9288
Sep 16 22:47:55 hp-dl320g5-01 automount[9267]: attempting to mount entry /nfsmp/systmp
Sep 16 22:47:55 hp-dl320g5-01 automount[9267]: lookup_mount: lookup(file): looking up systmp
Sep 16 22:47:55 hp-dl320g5-01 automount[9267]: lookup_mount: lookup(file): systmp -> -nobind,rw,rdma   127.0.0.1:/tmp
Sep 16 22:47:55 hp-dl320g5-01 automount[9267]: parse_mount: parse(sun): expanded entry: -nobind,rw,rdma   127.0.0.1:/tmp
Sep 16 22:47:55 hp-dl320g5-01 automount[9267]: parse_mount: parse(sun): gathered options: nobind,rw,rdma
Sep 16 22:47:55 hp-dl320g5-01 automount[9267]: parse_mount: parse(sun): dequote("127.0.0.1:/tmp") -> 127.0.0.1:/tmp
Sep 16 22:47:55 hp-dl320g5-01 automount[9267]: parse_mount: parse(sun): core of entry: options=nobind,rw,rdma, loc=127.0.0.1:/tmp
Sep 16 22:47:55 hp-dl320g5-01 automount[9267]: sun_mount: parse(sun): mounting root /nfsmp, mountpoint systmp, what 127.0.0.1:/tmp, fstype nfs, options nobind,rw,rdma
Sep 16 22:47:55 hp-dl320g5-01 automount[9267]: mount_mount: mount(nfs): root=/nfsmp name=systmp what=127.0.0.1:/tmp, fstype=nfs, options=nobind,rw,rdma
Sep 16 22:47:55 hp-dl320g5-01 automount[9267]: mount_mount: mount(nfs): nfs options="rw,rdma", nobind=1, nosymlink=0, ro=0
Sep 16 22:47:55 hp-dl320g5-01 automount[9267]: mount_mount: mount(nfs): calling mkdir_path /nfsmp/systmp
Sep 16 22:47:55 hp-dl320g5-01 automount[9267]: mount_mount: mount(nfs): calling mount -t nfs -s -o rw,rdma 127.0.0.1:/tmp /nfsmp/systmp
                <<<---  verified

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

http://rhn.redhat.com/errata/RHBA-2013-1690.html