> 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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Mon Jun 23 2003 - 22:00:21 EST