On 03-May-2000 Alexander Viro wrote:
> 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).
This doesn't happen because the kernel code makes sure the umount is
always possible once it told the daemon about it. There's some of the recovery
code in the daemon, but it never gets run.
> 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.
This would be broadly useful for autofs, since its pretty much what's required
to implement direct mounts. This would allow us to do incremental mount and
expiry of individual filesystems in the tree without having to do them en mass
like autofs4 currently does. It also means we don't need a special autofs4
filesystem mounted, because we can garnish the namespace without it. It
doesn't hurt that direct mounts are about the #1 requested feature.
I know hpa has been thinking about how to stack dentries. How does this
compare?
BTW, what happens if you umount a filesystem which has these scattered about
its namespace? Do they get cleaned up as part of the umount (appropriate
callback, etc), or do you need to clear them out before the umount? I prefer
the former.
Also, what happens if you attach one to a non-directory? Could you use it to
put arbiary "special files" into the namespace without having to do anything
special? It would make thinks like Pavel's podfuk more useful without having
to do horrible namespace hacks as he does now.
Also, when one is inserted between two real filesystems, it still needs to be
able to mediate namespace lookups. Autofs may need this to block access to a
filesystem while the daemon is umounting 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's not a huge issue, since you run out pretty quickly with NFS's
consumption.
> Jeremy, would you be OK with keeping the information about
> difference between regular negatives and mountpoints-to-be that way?
I like it. I've been thinking about something pretty similar, so I pretty much
know how I'd use it.
J
