Hide Forgot
Description of problem: when user has a symlink that points to some location in automounted directories and lists the directory containing the link, the FS mounts even though it is not necessary. This behaviour leads to long timeouts when e.g. the FS is not reachable Version-Release number of selected component (if applicable): autofs-5.0.5-39.el6_2.1.x86_64 How reproducible: always Steps to Reproduce: 1. verify that there are no autofs-managed filesystems mounted 2. create a symlink in /mnt to some auto-mounted directory: ln -s /net/your_nfs_server_hostname/path /mnt/symlink 3. list /mnt directory: ls /mnt Actual results: /net/your_nfs_server_hostname/path gets mounted Expected results: autofs doesn't try to mount the fs until 'ls /mnt/symlink' is called Additional info:
(In reply to comment #0) > Description of problem: > when user has a symlink that points to some location in automounted directories > and lists the directory containing the link, the FS mounts even though it is > not necessary. > > This behaviour leads to long timeouts when e.g. the FS is not reachable > > Version-Release number of selected component (if applicable): > autofs-5.0.5-39.el6_2.1.x86_64 > > How reproducible: > always > > Steps to Reproduce: > 1. verify that there are no autofs-managed filesystems mounted > 2. create a symlink in /mnt to some auto-mounted directory: > ln -s /net/your_nfs_server_hostname/path /mnt/symlink > 3. list /mnt directory: > ls /mnt > > Actual results: > /net/your_nfs_server_hostname/path gets mounted > > Expected results: > autofs doesn't try to mount the fs until 'ls /mnt/symlink' is called Basically, that's not possible. But see bug 787595 for an discussion of why the perceived behaviour has changed. I suspect we will be closing this as a duplicate once you have.
btw, to discuss this further you'll need to provide kernel version too since there are small differences between recent kernels.
(In reply to comment #2) > btw, to discuss this further you'll need to provide kernel > version too since there are small differences between recent > kernels. I noticed this behaviour on 6.2+ kernels, I'm not sure about behaviours of previous kernels. Now I'm running 6.3 nightly with: 2.6.32-244.el6.x86_64
There were kernels where stat(2) would trigger a mount, see bug bug 745775 for patches which (should have) changed this. The last time I looked at this (bug 787595) colour ls did an lstat(2) followed by a readlink(2) and looking at the kernel code I believed that the readlink(2) call would trigger a mount. Looking again just now it looks like it won't so for kernel revision 238 and later this shouldn't happen. What's even more puzzling is that testing with an older kernel without any of these changes the symlink mount also occurred. I'll have to continue looking. An strace of your command and maps used will help with this.
This request was not resolved in time for the current release. Red Hat invites you to ask your support representative to propose this request, if still desired, for consideration in the next release of Red Hat Enterprise Linux.
This request was erroneously removed from consideration in Red Hat Enterprise Linux 6.4, which is currently under development. This request will be evaluated for inclusion in Red Hat Enterprise Linux 6.4.
(In reply to comment #4) > There were kernels where stat(2) would trigger a mount, see > bug bug 745775 for patches which (should have) changed this. > > The last time I looked at this (bug 787595) colour ls did an > lstat(2) followed by a readlink(2) and looking at the kernel > code I believed that the readlink(2) call would trigger a > mount. Looking again just now it looks like it won't so > for kernel revision 238 and later this shouldn't happen. > What's even more puzzling is that testing with an older > kernel without any of these changes the symlink mount > also occurred. > > I'll have to continue looking. > An strace of your command and maps used will help with this. From RHEL-6.3 the automount behaviour is the same as it previously was and the same as upstream. Accessing a symlink as described here will cause the automount to be mounted unless the browse option is used. This has always been the way this has behaved. The request here amounts to, in some way, be able to behave in two different ways within the kernel for the exact same system call. It just isn't possible. You can use the browse option to prevent the mounting and it is worth you investiating its use. We recommend against using this option for large indirect maps due to possible performace impact. I think this bug needs to be closed as CANTFIX. Note that there has been quite a bit of work put into improving interacive response when unavailable servers are encountered. That change was needed due the changes in nfs-utils not autofs. Ian
Closing per Ian's comment above. We can reopen if you disagree. Thanks!