lkml.org 
[lkml]   [2004]   [Jan]   [9]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [autofs] [RFC] Towards a Modern Autofs
    Ian Kent wrote:

    >On Thu, 8 Jan 2004, Mike Waychison wrote:
    >
    >
    >
    >>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?
    >
    >
    >
    Al is proposing doing the same thing directly in the VFS instead of
    using a magic filesystem as I've described in the document.

    > Indeed, I
    >haven't solved my requirement of a transparent autofs filesystem aka.
    >Solaris automounter again. A difficult problem that will require
    >considerable effort.
    >
    >
    >
    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.

    >>>>This 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)?
    >>>
    >>>
    >>>
    >>>
    >>>
    >>Yes, it is its own filesystem (type autofs). This is needed because we
    >>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.
    >
    >
    >
    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.

    >>?? 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.
    >
    >
    >
    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.

    >>>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.
    >
    >
    >
    No, you're module doesn't use vfsmount_lock. At least the module in
    autofs4-2.4-module-20031201.tar.gz doesn't.

    >>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.
    >
    >
    >
    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.

    >>>Hang on. From the discussion my impression of a lazy mount is that it is
    >>>not actually mounted!
    >>>
    >>>
    >>>
    >>>
    >>>
    >>Lazy _un_mounts as opposed to lazy mounts. Lazy unmounts are described
    >>in umount(8):
    >>
    >>
    >
    >But will this leave the filesystem in a consistent state and allow further
    >mount activity on that mount point?
    >
    >
    The underlying autofs filesystem? Sure.


    --
    Mike Waychison
    Sun Microsystems, Inc.
    1 (650) 352-5299 voice
    1 (416) 202-8336 voice
    mailto: Michael.Waychison@Sun.COM
    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.
    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    [unhandled content-type:application/pgp-signature]
    \
     
     \ /
      Last update: 2005-03-22 13:59    [W:0.664 / U:0.364 seconds]
    ©2003-2011 Jasper Spaans. Advertise on this site