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 - nested mounts always take 10 seconds because of global lock
Summary: nested mounts always take 10 seconds because of global lock
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: autofs
Version: 3.0
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Jeff Moyer
QA Contact: Brock Organ
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2005-04-13 16:45 UTC by David Lehman
Modified: 2007-11-30 22:07 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2005-09-20 17:55:50 UTC
Target Upstream Version:


Attachments (Terms of Use)

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.


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