Bug 253973

Summary: mount does not honour "tcp" option correctly with NFS mounts
Product: Red Hat Enterprise Linux 3 Reporter: Pieter Krul <pkrul>
Component: mountAssignee: Karel Zak <kzak>
Status: CLOSED WONTFIX QA Contact: Brian Brock <bbrock>
Severity: medium Docs Contact:
Priority: low    
Version: 3.8   
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2007-10-19 18:35: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:
Attachments:
Description Flags
Patch to honour tcp option none

Description Pieter Krul 2007-08-23 11:38:12 UTC
Description of problem:

Since mount-2.11y-31.13 the UDP protocol is force-tried first even when TCP has
been specified.

This is a feature change from mount-2.11y-31.11, since all versions released
after that do not honour the tcp option directly, causing very long delays in
mounting NFS shares over TCP when UDP is not available.

A simple patch for this issue is attached.

Version-Release number of selected component (if applicable):
mount-2.11y-31.18 and later

How reproducible:
Always

Steps to Reproduce:
1. Mount filesystem from remote share with tcp option on a network where UDP
packets are dropped with version of mount newer than 2.11y-31.11

Actual results:
Mounting a remote filesystem takes ~2-5 minutes

Expected results:
Mounting a remote filesystem should take no longer than a few milliseconds

Additional info:

Reproducer as follows

[root@benzin tmp]# iptables -A INPUT -p udp --sport 53 -j ACCEPT

[root@benzin tmp]# iptables -A INPUT -p udp -j DROP



[root@benzin tmp]# rpm -qi mount

Name        : mount                        Relocations: (not relocatable)

Version     : 2.11y                             Vendor: Red Hat, Inc.

Release     : 31.23                         Build Date: Mon 14 May 2007 10:43:28
AM CEST

Install Date: Thu 23 Aug 2007 12:38:30 PM CEST      Build Host:
hs20-bc1-6.build.redhat.com

Group       : System Environment/Base       Source RPM:
util-linux-2.11y-31.23.src.rpm

Size        : 160806                           License: distributable

Signature   : DSA/SHA1, Mon 14 May 2007 08:08:46 PM CEST, Key ID 219180cddb42a60e

Packager    : Red Hat, Inc. <http://bugzilla.redhat.com/bugzilla>

Summary     : Programs for mounting and unmounting filesystems.

Description :

The mount package contains the mount, umount, swapon, and swapoff

programs. Accessible files on your system are arranged in one big tree

or hierarchy. These files can be spread out over several devices. The

mount command attaches a filesystem on some device to your system's

file tree. The umount command detaches a filesystem from the

tree. Swapon and swapoff, respectively, specify and disable devices

and files for paging and swapping.



[root@benzin tmp]# time /bin/mount -t nfs -o tcp hoover:/oracle /tmp/nfstest/
pmap_getmaps rpc problem: RPC: Timed out



real    2m0.292s

user    0m0.000s

sys     0m0.000s



[root@hoover tmp]# ls /tmp/nfstest/

db1  db2  db3  db4


When using the attached patch, the protocol will default to tcp when specified,
and use udp when no protocol or udp has been specified 

[root@benzin tmp]# time /bin/mount -t nfs -o tcp hoover:/oracle /tmp/nfstest/
real    0m0.060s

user    0m0.000s

sys     0m0.000s

Comment 1 Pieter Krul 2007-08-23 11:40:06 UTC
Created attachment 168580 [details]
Patch to honour tcp option

Comment 2 RHEL Program Management 2007-10-19 18:35:31 UTC
This bug is filed against RHEL 3, which is in maintenance phase.
During the maintenance phase, only security errata and select mission
critical bug fixes will be released for enterprise products. Since
this bug does not meet that criteria, it is now being closed.
 
For more information of the RHEL errata support policy, please visit:
http://www.redhat.com/security/updates/errata/
 
If you feel this bug is indeed mission critical, please contact your
support representative. You may be asked to provide detailed
information on how this bug is affecting you.