Bug 510234

Summary: Document which options are shared and which are not when mounting multiple volumes from the same server
Product: Red Hat Enterprise Linux 5 Reporter: Fabio Olive Leite <fleite>
Component: nfs-utilsAssignee: Steve Dickson <steved>
Status: CLOSED DUPLICATE QA Contact: BaseOS QE <qe-baseos-auto>
Severity: medium Docs Contact:
Priority: medium    
Version: 5.3CC: jlayton, staubach, steved
Target Milestone: rc   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2009-10-13 15:15:31 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Fabio Olive Leite 2009-07-08 12:59:21 UTC 
Description of problem:

The addition of the nosharecache option allows an admin to force the mounting of the same volume more than once with different options, but even then some options are bound to the internal NFS client for that server and cannot be changed. For example, on RHEL-5.3 it seems timeo, bg and proto are not changed in mounts after the first one. It is important that the manpage documents what really is shared by multiple mounts and what is not.

Version-Release number of selected component (if applicable):

nfs-utils-1.0.9-40.el5

How reproducible:

Always.

Steps to Reproduce:

# mount -o udp,nosharecache server:/export/nfs /mnt1

# mount -o tcp,nosharecache,timeo=123,rsize=8192,wsize=8192,soft server:/export/nfs /mnt2
  
Actual results:

# grep server /proc/mounts 

server:/export/nfs /mnt1 nfs rw,vers=3,rsize=32768,wsize=32768,hard,nosharecache,proto=udp,timeo=11,retrans=2,sec=sys,addr=server 0 0

server:/export/nfs /mnt2 nfs rw,vers=3,rsize=8192,wsize=8192,soft,nosharecache,proto=udp,timeo=11,retrans=2,sec=sys,addr=server 0 0

Notice proto, timeo.

Expected results:

Documentation states correctly what is always shared and what is not, so that an admin can know what to expect.
Comment 1 Peter Staubach 2009-09-25 20:28:17 UTC 
The transport protocol sharing is a bug.  See RH bz#460659.
Comment 2 Steve Dickson 2009-10-13 15:15:31 UTC 

*** This bug has been marked as a duplicate of bug 460659 ***