Hide Forgot
Description of problem: Automounting NFS via RDMA fails since it only probes with TCP/UDP: sun_mount: parse(sun): mounting root /home, mountpoint hostname, what server.example.com:/share, fstype nfs, options nfsvers=4,rdma,port=2050,rw,nosuid,softq mount_mount: mount(nfs): root=/home name=hostname what=server.example.com:/share, fstype=nfs, options=nfsvers=4,rdma,port=2050,rw,nosuid,softq mount_mount: mount(nfs): nfs options="nfsvers=4,rdma,port=2050,rw,nosuid,softq", nosymlink=0, ro=0 get_nfs_info: called with host hostname(192.168.8.13) proto tcp version 0x70 get_nfs_info: called with host hostname(192.168.8.13) proto udp version 0x70 mount(nfs): no hosts available Version-Release number of selected component (if applicable): kernel 2.6.32-279.14.1.el6 autofs-5.0.5-55.el6_3 How reproducible: Always Steps to Reproduce: 1. Setup an NFS client to mount using autofs and proto=rdma: directory -fstype=nfs,nfsvers=4,rdma,port=2050,rw,nosuid,softq server.example.com:/share 2. cd into the directory autofs is monitoring an issue a 'ls' to make autofs begin the automount process. 3. The NFS share will never be mounted Actual results: autofs fails to mount NFS shares via RDMA. Expected results: autofs mounts NFS shares via RDMA. Additional info: - Mounting directly works fine: # mount -o nfsvers=4,rdma,port=2050,rw,nosuid server.example.com:/share /mnt Gives no error, returns the prompt. # mount server.example.com:/share on /mnt type nfs (rw,nosuid,nfsvers=4,rdma,port=2050,addr=192.168.8.13,clientaddr=192.168.9.11) - 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. - It looks like this was introduced with autofs-5.0.6-reinstate-singleton-mount-probe.patch
(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