Re: [PATCH] VFS autmounter support

[David Howells <dhowells@warthog.cambridge.redhat.com>]

> This seems a bit heavyweight; although some VFS support is needed for
> a complex filesystem, effectively doing it all in the kernel (#3)
> seems a bit... excessive.

One of the problems I have to deal with is namespaces. This means I can't just
have an automounter running in userspace that's passed requests to mount
things as it might not be able to access the target namespace.

Doing it this way means that I don't need to care which namespace the
automount needs to take effect in. I can just return a vfsmount to the VFS (as
acquired from do_kern_mount()) and let that paste it into the right place.

Furthermore, for AFS at least, it's a lot less excessive than, say, calling
back into userspace.

> At least #2 can be done with existing means using follow_link.

How? I want to be able to mount on the location in question (so it has to be a
directory), but I don't want "ls -l" to cause it to mount (otherwise
accidentally doing that or tab expansion if /afs, say, will take ages).

Maybe you mean construct a symlink that points to somewhere I can actually
mount the filesystem? If so, that too can suffer from namespace problems.

Whatever happens, stat() must _not_ cause the automount point to mount.

> I think using a revalidation pointer like dentries might be a better
> way to do #4/#5, although using the existing one in the dentries is
> probably better.

Do you mean dispose of the expired mount point when it's next revalidated? If
so, surely you _don't_ want to do it then, as that's normally a prelude to
reusing it.

Or do you mean do it actually inside dentry->d_op->d_revalidate()? But you
can't do it there because you don't know what vfsmount you are dealing with.

> #1 isn't really clear to me what you're going for, but it seems to be
> to duplicate bookkeeping.

Duplicate of what bookkeeping?

The fact that the operation is provided indicates that a dentry is an
automount point, and as such should be handled specially by path-walk. All the
logic to link the new vfsmount into the filesystem topology can be handled
easily by the VFS at that point because all the details are to hand.

> I also don't see how this solves the biggest problems with complex
> automounts, which are:
> 
> a) how to guarantee that a large mount tree can be safely destroyed;

What do you mean by safely? I check that the usage count on vfsmount
structures is 1 under lock just before unlinking it - thereby making sure that
no one has a file open on it, no process has it as its root or cwd, and that
nothing is mounted upon it.

Also, I do the actual unmounting from process context by walking the
namespace's extant mount list, rather than directly nominating a vfsmount for
removal.

One drawback is that - taking AFS as an example - doing a umount of /afs won't
work until all the subtrees have either been manually unmounted or have
expired (though I can make umount capable of handling this).

> b) how to detect partial unmounts.

What do you mean by a partial unmount?

David