On Thu, 8 Jan 2004, Mike Waychison wrote:Al is proposing doing the same thing directly in the VFS instead of using a magic filesystem as I've described in the document.
The direct map 'triggers' will be taken care of by another filesystem
with a magic root directory that will catch traversals using some
follow_link magic. I wrote a prototype for this last summer, but
haven't released it as the userspace stuff completely does not fit in
with the existing daemon that was out at the time do the the mess of
glue that was pgids, pipes and processes. It worked in the simple
case, but it didn't extend to being able to direct mount an indirect
map, nor was it able to do the lazy mounting in multimounts as I had
desired.
Is this the stuf that Al Viro is working on?
What do you mean by this? Something that doesn't show up in /proc/mounts? I don't see this as much of an issue.. On any decently large machine, there are so many entries anyway that /etc/mtab and /proc/mounts become humanly unparseable anyhow.Indeed, I haven't solved my requirement of a transparent autofs filesystem aka. Solaris automounter again. A difficult problem that will require considerable effort.
Yup. But still, one of the nice things about a full automounter solution is accessing a netapp with hundreds of exports through /net in a reasonably fast way.Yes, it is its own filesystem (type autofs). This is needed because weThis is the subtle difference between direct and indirect maps. The direct map keys are absolute paths, not path components. We are implementing direct mounts as individual filesystems that will trap on traversal into their base directory. This filesystem has no idea where it is located as far as the user is concerned. We need to tell the filesystem directly so that the usermode helper can look it up. Conversely, the indirect map uses the sub-directory name as a mapkey.
I'm not sure what you are saying here. Does this mean there is a mount for every direct mount (this might be what you call a trigger)?
need to overlay direct triggers within NFS filesystems for multimounts.
Ahh. I see, you are talking about the cross filesystem problem. I haven't solved that in what I have done either. Fortuneately I still get a good hit rate in satisfying peoples' needs as in practice many people don't use full automounter functionality.
Could be. Either way, on a system with a thousand NFS shares automounted, I'm not really concerned about what the mounttable looks like. It won't be human parseable anyway.?? Really? I find that hard to believe. I thought Solaris shared it's
automounter with HPUX and AIX. I may be wrong though.
Old versions perhaps. AIX 4.x was the last I used. It was definately like that then. 500+ automounts tends to cluter the mount display a bit.
No, you're module doesn't use vfsmount_lock. At least the module in autofs4-2.4-module-20031201.tar.gz doesn't.Mmm. The vfsmount_lock is available to modules in 2.6. At least it was in test11. I'm sure I compiled the module under 2.6 as well???
I thought that, taking the dcache_lock was the correct thing to do when traversing a dentry list?
Walking dentrys still takes the dcache_lock, however walking vfsmounts takes the vfsmount_lock. dcache_lock is no longer used for fast path walking either (to the best of my understanding).
find . -name '*.[ch]' -not -path '*SCCS*' | xargs grep vfsmount_lock |
grep EXPORT
Strange. How does the module compile I wonder? How does it load without unresolved symbols? Another little mystery to work on.
This isn't lazy mounting per se. If you are talking about autofs4's use of AUTOFS_INF_EXPIRING, it's there to prevent somebody from walking into a multimount while it is expiring.The raciness comes from the fact that we now support the lazy-mounting
of multimount offsets using embedded direct mounts. Autofs4 mounts all
(or as much as it can) from the multimount all together, and unmounts it
all on expiry.
But 4.1 does lazy mount for several maps. Mounts that are triggered during the umount step of the expire are put on a wait queue along with the task requesting the umount. I think autofs always worked that way.
The underlying autofs filesystem? Sure.Lazy _un_mounts as opposed to lazy mounts. Lazy unmounts are describedHang on. From the discussion my impression of a lazy mount is that it is not actually mounted!
in umount(8):
But will this leave the filesystem in a consistent state and allow further
mount activity on that mount point?
-- 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
