To: "H. Peter Anvin" <hpa@zytor.com>
cc: linux-kernel@vger.kernel.org, dhowells@redhat.com
Subject: Re: [PATCH] VFS autmounter support 
In-Reply-To: Message from "H. Peter Anvin" <hpa@zytor.com> 
   of "17 Jun 2003 09:08:28 PDT." <bcneds$or6$1@cesium.transmeta.com> 
User-Agent: EMH/1.14.1 SEMI/1.14.4 (Hosorogi) FLIM/1.14.4
 (=?ISO-8859-4?Q?Kashiharajing=FE-mae?=) APEL/10.4 Emacs/21.2
 (i386-redhat-linux-gnu) MULE/5.0 (SAKAKI)
MIME-Version: 1.0 (generated by SEMI 1.14.4 - "Hosorogi")
Content-Type: text/plain; charset=US-ASCII
Date: Tue, 17 Jun 2003 19:07:37 +0100
Message-ID: <16634.1055873257@warthog.warthog>
From: David Howells <dhowells@warthog.cambridge.redhat.com>
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 3247
Lines: 76


> 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/