Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.

Bug 154703

Summary: nested mounts always take 10 seconds because of global lock
Product: Red Hat Enterprise Linux 3 Reporter: David Lehman <dlehman>
Component: autofsAssignee: Jeff Moyer <jmoyer>
Status: CLOSED WONTFIX QA Contact: Brock Organ <borgan>
Severity: medium Docs Contact:
Priority: medium    
Version: 3.0CC: cfeist, tao
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: 2005-09-20 17:55:50 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Description David Lehman 2005-04-13 16:45:00 UTC
Description of problem:
Nested mounts always wait 10 seconds before stealing the autofs lock which is
held by the parent automount process.

For example request for, say, /home/nyc/joe triggers another automount of
/export/home, then a bind mount of /export/home/joe to /home/nyc/joe. This
operation always takes at least 10 seconds since the automount process trying to
mount /home/nyc/joe has the global lock while calling /bin/mount and therefore
the child automount must wait 10 seconds before taking this lock and satisfying
the /export/home prerequisite mount.

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

How reproducible:
Always

Steps to Reproduce:
1. Set up two autofs mountpoints as follows
  /misc/test1   other_host:/some/path
  # we need to specify two hosts below or autofs won't try a bind mount at all
  /foo/test2    localhost:/misc/test1 other_host:/some_other_path
2. restart autofs
3. time ls /foo/test2
  
Actual results:
it takes just over 11 seconds

Expected results:
it takes maybe 2 seconds

Additional info:

Comment 1 Jeff Moyer 2005-04-13 23:13:38 UTC
Please post the contents of the auto.master map and the other relevant maps.

Comment 6 Jeff Moyer 2005-04-27 22:20:09 UTC
Because autofs can potentially issue a large number of mount requests
concurrently, and because the mount command has a built-in timeout when waiting
for a lock to update /etc/mtab, automount was written to try to serialize its
access to the mount command.  This is the purpose of the global lock.

Simply removing this lock is not an option.  Making the timeout shorter may be,
but I'm not certain that is an optimal solution either.  Ideally, we would be
able to detect recursive mounts such as this.

Note that in 4.1.4, autofs does not even overwrite the old lock;  instead, it
simply returns failure.  So, this was either an oversight by the author, or this
configuration is not intended to work.

I have sent mail to the upstream maintainer, asking if he was aware of the newly
imposed limitation.  I will work with him to determine the correct way to
address this problem.

Comment 7 Jeff Moyer 2005-04-28 18:11:45 UTC
According to the upstream maintainer, nested mounts are not supported by Sun,
and are not supported by Linux, either.

If you could elaborate on why things are setup this way, perhaps we can find
another solution.

Comment 11 Jeff Moyer 2005-09-20 17:55:50 UTC
It seems the reporter lost interest in this issue.  I'm closing as WONTFIX. 
Please reopen if appropriate.