Re: autofs vs. Sun automount -- new fs proposal
Richard Gooch (rgooch@atnf.csiro.au)
Tue, 15 Dec 1998 15:13:59 +1100
David Mansfield writes:
>
> The Solaris automounter allows a "seamless" mount of a local directory
> onto another place on the local filesystem. This is frequently used, for
> example, when a user logs in to the actual fileserver. The home directory
> is usually located at /export/home/joeblow and is automounted to
> /home/joeblow when referenced. This could, of course, be achieved by
> actually NFS mounting from the local server. I'd rather shoot myself
> however (am I sure Solaris doesn't do this? no)
>
> autofs can do this. However, it does so trivially by creating a
> symbolic link which is then traversed. This has mostly cosmetic
> disadvantages, but a few more substatial ones. Any subprocess will see
> the actual 'pwd' of /export/home/joeblow. Thus inexperienced users will
> get confused and bother their system administrator, and, more seriously,
> an application may wrongly determine the location of its private files,
> defeating the 'logical structure' of the filesystem, and preventing
> restructuring of the physical layout.
>
> So the question is, how difficult would it be to make a fs implementation
> that redirected requests for its top level directory to another fs'es
> directory, and did all the necessary house keeping. Would it be possible
> to just deal with the top level directory, or would all fs requests pass
> through a layer of interpretation?
>
> As you can tell by now, my knowledge of the linux fs internals is very
> limited. I have merely scratched the surface of the linux source, but I
> would love to learn and this sounds like something doable. From reading
> some of the archives on this subject it seems like something others might
> be interested in having.
You are describing lofs, the loopback filesystem. There are
apparentely 2 ways to implement this:
1) the sledgehammer approach, which doesn't affect the VFS
2) the clean approach which requires VFS changes.
(1) could possibly go in before 2.2 is released, provided that someone
has the time to code it up quickly and test it and have tested widely
before Linus releases 2.2. Volunteers step forwards now.
(2) this is definately a 2.3 job. By the time 2.3 is released, I
should (hopefully) have more time available and I could then implement
this. Alternatively, hpa (author of autofs) or someone else may beat
me to it. Hopefully anyone who starts working on it will first send an
annoucement to linux-kernel so we don't end up with multiple efforts.
Note also that the VFS changes required for (2) may never make it into
2.2, because Linus is more reluctant to make fundamental changes to a
production kernel. I don't know how he views such a change, but it's
worth considering. It may mean we won't have a "clean" lofs in
2.2. However, that doesn't mean we can't have the quick and dirty
implementation in 2.2. So it may be worthwhile writing (1) anyway, so
we can have a clean lofs in 2.3 but still have something working for
2.2. This would also be helpful for the autofs automount(8), so it
doesn't have to worry about kernel versions. Although I suppose it
could always scan /proc/filesystems to check if lofs is available.
Regards,
Richard....
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/