> 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.
Yup. That's what UMSDOS tries to do. And it's broken.
> [*] 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'.
Not that simple. Linux VFS differs from 4.4BSD one - our lookup()
method sits in inode. Good to have such beasts in vnode layer and do
everything from there, but... We'll have to do it in harder way.
> The interface between the filesystem and the VFS is a little fuzzy
> with respect to inodes and dentries. Some work might be required to
Yes. That's what I'm hacking on since September.
rmdir()/rename()/unlink()/mknod() cleanup in 131-ac* is byproduct of that
hacking - I've stumbled across the bugs that were way too serious to leave
them till 2.3 ;-/ Current showstopper being how to deal with FAT-based
filesystems. They do lots of nasty things to dentry layer (e.g. flip inode
under living dentry). It's an artefact of the old scheme (no dentries, all
lookups go through inodes), but now it can be fixed. After I'll clean that
up (and find enough people to test it - hint, hint ;-) I'm going to do
partial rewrite of fs/namei.c (lookup and namespace-changing operations)
to obtain atomic lookups (that would exterminate most of fs races). Then
the stacked filesystems will go. I know how to do it, but right now we
have a mess on the border between VFS and filesystems and hacking anything
into that mess wouldn't do any good.
> give better separation between the layers, and it would be nice if the
> filesystems didn't have to worry about dentries at all.
If you think of moving some operations to dentry layer - forget
it. inode_operations is used by drivers. MANY drivers. Third-party ones at
that. Moreover, we don't actually need that - there is cleaner solution.
> 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.
Nah. Not the way to go - what we need is a *stack* of dentries.
Al
-
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/