|Summary:||nested mounts always take 10 seconds because of global lock|
|Product:||Red Hat Enterprise Linux 3||Reporter:||David Lehman <dlehman>|
|Component:||autofs||Assignee:||Jeff Moyer <jmoyer>|
|Status:||CLOSED WONTFIX||QA Contact:||Brock Organ <borgan>|
|Fixed In Version:||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||2005-09-20 17:55:50 UTC||Type:||---|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
|Cloudforms Team:||---||Target Upstream Version:|
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.