Folks, I've tried to describe the stuff that may IMO become useful
for autofs/devfs/portalfs/etc. Comments are more than welcome.
Current problems:
1. autofs would be much simpler if we had some way to distinguish
between the real negative dentries and mountpoints-to-be-triggered.
Especially autofs4.
2. It would be nice if we could treat all mounts in the tree
created by autofs the same way. IOW, get the expiry stuff independently
for all of them, not just for the layer closest to autofs. The main
problem with that is the way we trigger such mounts - it's done in autofs4
->lookup() and that means that once we got a mount deep in the tree
expired there will be no way to get it back. Not nice. Thus the need to
scan the whole tree from the autofs code, play the games with remounting
stuff if expiry fails in the middle (somebody went into /mnt/net/foo while
we were umounting /mnt/net/foo/bar and that made umount /mnt/net/foo
fail; have to remount everything). Thus the problems with handling the
policy stuff in the kernel (nobody should mount by hands anywhere under
autofs), etc.
3. In principle, it would be nice if daemon told where the
potential mountpoints are from the very beginning. However, we lack the
object to hold such information.
4. All the stuff with triggering mounts/expiry attempts looks like
a VFS fodder. For one thing, it's localized. It's a node in unified tree,
not the whole chunk. autofs just happens to carry such points, but we
would really win a lot if we allowed them anywhere.
5. Any schemes with automount-like stuff in devfs require
(union-)mount being triggered if lookup brings negative in all components
already mounted. IOW, if the search gets to the last component of
union-mount.
6. portalfs is another example of notifications sent to userland
upon a lookup reaching the mountpoint (the rest of name being passed to
daemon which should return the object).
So what about the following trick: let's allow vfsmounts without
associated superblock and allow to "mount" them even on the negative
dentries? Notice that the latter will not break walk_name() - checks for
dentry being negative are done after we try to follow mounts.
Notice also that once we mount something atop of such vfsmount it
becomes completely invisible - it's wedged between two real objects and
following mounts will walk through it without stopping.
So the only case when these beasts count is when they are
"mounted", but nothing is mounted atop of them. But that's precisely the
class of situations we are interested in. In case of autofs we want
follow_down() into such animal to trigger mounting, in case of portalfs -
passing the rest of pathname to daemon, in case of devfs-with-automount
we want to kick devfsd. So let them have a method that would be called
upon such follow_down() (i.e. one when we have nothing mounted atop of
us). And that's it.
These objects are not filesystems - they rather look like a traps
set in the unified tree. Notice that they do not waste anon device like
"one node autofs" would do.
That way if autofs daemon mounted /mnt/net/foo it would not follow
up with /mnt/net/foo/bar - it would just set the trap in /mnt/net/foo/bar
and let the actual lookups trigger further mounts.
Notice that we can also remove a lot of special-case code from
autofs: just make the lookup in mount() _not_ follow mounts on the last
step and there we are - mount(8) can be called by autofs daemon without a
black magic currently needed to prevent recursive invoking the mount upon
attempt to look the mountpoint up.
The bottom line: I propose to
a) remove ->mnt_dev from struct vfsmount (not used by any code in the
tree, it's a rudiment of old scheme where we used to search by device
number).
b) add a method (say it, ->mnt_trigger()) that would be called when
follow_down() finds vfsmount with NULL ->mnt_sb and nothing mounted
on that vfsmount.
c) add a way (flag to mount, whatever) for mounting such "traps".
Removal is probably best done by umount().
d) add LOOKUP_NO_DOWN - takes effect only on the last component, prevents
calls of follow_down(). Used by lookup of mountpoint in mount().
e) see what can be simplified in the autofs4 and possibly devfs if we use
such "traps".
I can do that and I suspect that it may seriously simplify the
life. If anyone has objections/sees obvious holes in the scheme - I'ld
like to hear about that.
Jeremy, would you be OK with keeping the information about
difference between regular negatives and mountpoints-to-be that way?
Linus, what do you think about such beast? It's a seriously
differnt way of doing autofs-like stuff, but I think that it's may be the
Right Thing(tm). Would you accept such objects?
Cheers,
Al
