Bug 154703 - nested mounts always take 10 seconds because of global lock
nested mounts always take 10 seconds because of global lock
Status: CLOSED WONTFIX
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: autofs (Show other bugs)
3.0
All Linux
medium Severity medium
: ---
: ---
Assigned To: Jeffrey Moyer
Brock Organ
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2005-04-13 12:45 EDT by David Lehman
Modified: 2007-11-30 17:07 EST (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2005-09-20 13:55:50 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description David Lehman 2005-04-13 12:45:00 EDT
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 Jeffrey Moyer 2005-04-13 19:13:38 EDT
Please post the contents of the auto.master map and the other relevant maps.
Comment 6 Jeffrey Moyer 2005-04-27 18:20:09 EDT
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 Jeffrey Moyer 2005-04-28 14:11:45 EDT
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 Jeffrey Moyer 2005-09-20 13:55:50 EDT
It seems the reporter lost interest in this issue.  I'm closing as WONTFIX. 
Please reopen if appropriate.

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