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.232 / U:1.376 seconds]
©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site