Re: autofs vs. Sun automount -- new fs proposal

Peter Benie (pjb1008@cam.ac.uk)
Tue, 15 Dec 1998 15:41:46 +0000


Richard Gooch writes ("Re: autofs vs. Sun automount -- new fs proposal"):
> David Mansfield writes:
> >
> > The Solaris automounter allows a "seamless" mount of a local directory
> > onto another place on the local filesystem.
>
> 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.

I'm fairly convinced that (1) isn't possible.

I presume that you are imagining a solution involving keeping a copy
of each inode and dentry. This would enable a change to the looped back
inode to be passed down to the underlying[*] inode (although this would
require duplication of the work done by the VFS in several places).
However, changes to the underlying inode could not easily be
propogated to the loopback filesystem. Such an approach would be
_very_ hard to implement.

[*] By 'underlying inode', I mean the inode in the place where the
original filesystem was mounted, as opposed to the copy made by lofs.

IMHO, (2) is the only sensible approach. All lofs does is to twist
your file namespace slightly; it should be implemented purely in terms
of dentries. In fact, copies of the dentries only need to be made for
_directories_ in the looped back filesystem (so that '..' works at the
mountpoint); looped back files should 'just work'.

The interface between the filesystem and the VFS is a little fuzzy
with respect to inodes and dentries. Some work might be required to
give better separation between the layers, and it would be nice if the
filesystems didn't have to worry about dentries at all.

One of the 'gotchas' when implementing lofs is that when calling
open() on a directory, you have to store the looped back dentry; this
makes open() quite different to other fs operations. This is because
you don't want fchdir() to the wrong copy of the dentry, especially if
you are in a chrooted environment.

Peter

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