Urban Widmark wrote:
>
> On Wed, 10 Nov 1999, H. Peter Anvin wrote:
>
> > Urban Widmark wrote:
> > >
> > > Yes ... something like what devfs does? Creating directories for each
> > > server it finds (each server it's userspace daemon finds), creating
> > > subdirectories for each share (when someone accesses the dir).
> >
> > That's what autofs does. That far it is easy. The hard part is that a
>
> Ok, it can do that for both the server and the share "level". Good.
>
> > stat() is an *access*... and so, it should logically mount the share.
>
> Yes, normally. But typically you are perhaps not that interested in that
> info on the share? The thing you end up mounting you want updated with the
> correct times etc but the rest you may not care about. This will be an
> additional visible difference between the automounted directories and
> local directories, so it will probably break some type of usage (so it
> must be an optional behaviour).
>
That's yet another problem (semantic.) But the implementation problems
alone are hideous. Right now autofs triggers a mount on any request for
a lookup. This is nice, easy, and clean. However, if you want to do
mount filtering based on the operation that triggered a lookup, not only
do you need to worry about knowing what operation triggered the lookup,
you *ALSO* have the problem that you won't *get* the lookup the next
time anything comes looking for this directory, and it might be
something for which you really need to mount.
This gets very ugly very fast, and is probably undoable without VFS
changes, which would impose overhead for every operation for every
filesystem.
-hpa
