Bug 886623 - [autofs] Automounting NFS via RDMA fails
[autofs] Automounting NFS via RDMA fails
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: autofs (Show other bugs)
6.3
All Linux
medium Severity medium
: rc
: 6.5
Assigned To: Ian Kent
Yin.JianHong
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2012-12-12 12:09 EST by Kyle Squizzato
Modified: 2014-10-27 05:21 EDT (History)
3 users (show)

See Also:
Fixed In Version: autofs-5.0.5-77.el6
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-11-21 17:45:08 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Patch - dont probe rdma mounts (2.00 KB, patch)
2013-07-19 03:17 EDT, Ian Kent
no flags Details | Diff


External Trackers
Tracker ID Priority Status Summary Last Updated
Red Hat Knowledge Base (Solution) 278973 None None None Never

  None (edit)
Description Kyle Squizzato 2012-12-12 12:09:30 EST
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
Comment 1 Ian Kent 2013-01-09 21:10:08 EST
(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
Comment 2 Orion Poplawski 2013-05-07 11:51:12 EDT
Just ran into this myself.  MOUNT_WAIT works.
Comment 7 Ian Kent 2013-07-19 03:17:50 EDT
Created attachment 775658 [details]
Patch - dont probe rdma mounts
Comment 9 Yin.JianHong 2013-09-16 23:19:56 EDT
[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
Comment 10 errata-xmlrpc 2013-11-21 17:45:08 EST
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

Note You need to log in before you can comment on or make changes to this bug.