On Wed, 2008-06-25 at 15:41 -0700, Stephen Biggs wrote: > Automounter 5.0.3 unpatched, vanilla, 2.6.24 Linux kernel also vanilla. > > This is probably a really dumb question and the way I am doing it is > probably cause for some mirth, but if anybody have a better way, I am > all ears. > > I have /home as an indirect mount point using a yp:auto.home key file. > > I have an application that I have no control over nor ability to change > its behavior. It does many many searches for a file that I will call > .junk, starting at the cwd and going up the tree until it either finds / > or the file. If the user is anywhere under the /home directory, this > search eventually tries to open /home/.junk and fails, but not until it > triggers the automounter to try to mount a non-existent directory named > .junk. Because of the many searches, it seriously slows down execution > due to the automounting storm and consequent NFS dialogs over the > network. > > A solution would be to have a permanent empty /home/.junk file present > as a last resort fail point for an application that searches for this > file and causes an automount storm since it This seems to not be > possible because /home is a pseudo directory created by autofs as a > place to hang mounts off of (please correct me if this is an invalid > assumption).
Yes, only the owner daemon can do anything in an autofs file system. What about having an entry in the indirect map with a key .junk that mounts a temporary local mount instead of an actual direct mount? > > The best compromise I could think of was to have a /home/.junk directory > that is there the moment automounter comes up and stays there, on all my > systems. Then, the application can try to open it but not trigger the > automounter, at least no more than once. > > The best way I could see to do it was as such: > > On the local auto.master, I added the line: > /- /etc/auto.data > > ...before the /home entry. /etc/auto.data can be on the YP repository > some time in the future. > > In /etc/auto.data, I have one line: > /home/.junk -mode=555,fstype=tmpfs,ro :/.junk Haha, my first impulse was to say "you can't do that" since nesting isn't allowed (although it isn't checked for) with direct mounts, except when the direct mount entry is itself a multi-mount entry. But, thinking about it, the autofs mount on /home is just another mounted file system so, in theory, having a direct mount in it should work OK. But expect you will get difficulties with the direct and indirect mounts interfering with one another in strange ways. > > This seems to work just fine, except for a couple of weirdnesses: > 1. When I applied a -HUP to the automounter, it created a ghosted > directory with mode of 755 instead of 555. This may be fixed by Ian's > patches regarding "abuse" of ghosting. But, upon first access, the > directory (using ls -ld /home/.junkdirectory) then has the correct mode. > It looks like the local directory is remounted using the -bind option > and the proper mode. Yep, probably the unpredictable strangeness I mention above. Don't really have time to go into this at the moment but it may be worth trying to make this work. I suspect it will be fairly difficult though. > > 2. I think I saw the directory get expired and also all /- entries in > /var/log/messages. Then, "ls /home/.junkdirectory" came back with "ls: > /home/.junkdirectory: No such file or directory". If this is true (that > it will not be automounted again after expiration), then this is not a > good solution. If so, I am obviously misunderstanding direct mounts. > This may have been because of my testing where I needed to remove the > entry for /- in /etc/auto.master and forgot to send another HUP signal > to the automounter when I put it back in. If this is true, then there > should be no problem Is it possible that this can be expired off to the > point of not being able to be remounted? Could be anything causing that. Perhaps the order of checking, umounting and mounting again is causing over mounting but it's hard to say without spending time on it. Ian _______________________________________________ autofs mailing list [email protected] http://linux.kernel.org/mailman/listinfo/autofs
