On Fri, 9 Jan 2004, Mike Waychison wrote:Ok. Then the kernel would need to periodically make these checks.. It could work, but I see it as yet another communication kludge.
Jim Carter wrote:
No, I meant that when the sys_stat method fills in the mode field of
the returning stat structure, it would be reported as 555 for a busy
filesystem, or 755 if it looks idle and dismountable. The mode field as
seen by the VFS layer can stay at 755. This would be when statting
autofs's directory inode, not whatever is mounted on it.
This hijacking of the st_mode is just that, hijacking. You'd be
changing the mode of the directory on the NFS filesystem.. This
wouldn't work well in the VFS when it tries to check permissions, but it
also wouldn't work for more than one NFS client accessing the same
filehandle.
There are 2 inodes here: the mount point (owned by autofs) and what's mounted on it. We mustn't monkey with the mountee's data, of course. I'm talking about statting the mount point itself. You can't do that by name, but in a prior discussion we were talking about opening the mount point before the mount, and later doing fstat on the file descriptor. HPA mentioned providing a readlink method and doing lstat on the mount point by name, which would intercept the path walk before the mountee was noticed.
So the caller gets the mode of the mount point, which autofs can create or interpret any way it wants, rather than the mountee's data.
This probably isn't best placed in the initscript. The automount daemon should instead have a timeout setup for unmounting these filesystems. If the unmount hangs for more than x seconds, move on to the next one. Let init take care of killing off processes if they haven't died in time for shutdown.I would really like it if, when autofs decided to forcibly unmount, it
could kill the using processes, as in "fuser -k -m /net/host/mountpoint".
Actually this is a general issue for unmount(8), not specific to autofs.
But one wonders whether fuser is going to run wild...
Like HPA already mentioned, this is bad. I don't even think you could
reliably detect this.
Agreed, you wonder if the right processes are going to be picked. But... "Ask for the moon; they might give it to you." In the present case it should be possible to stick the fuser execution into the autofs shutdown script -- it already is aware that unmounts haven't finished, and it probably knows or can find out which filesystems are involved.
-- Mike Waychison Sun Microsystems, Inc. 1 (650) 352-5299 voice 1 (416) 202-8336 voice mailto: [EMAIL PROTECTED] http://www.sun.com
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
NOTICE: The opinions expressed in this email are held by me, and may not represent the views of Sun Microsystems, Inc.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
pgp00000.pgp
Description: PGP signature_______________________________________________ autofs mailing list [EMAIL PROTECTED] http://linux.kernel.org/mailman/listinfo/autofs
