Messages in this thread | | | Subject | Re: [PATCH] VFS autmounter support | Date | Tue, 17 Jun 2003 19:07:37 +0100 | From | David Howells <> |
| |
> 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/
| |