Re: [PATCH] VFS autmounter support

[David Howells]

> > > We need a light-weight automount.  No arguments here.  But it should
> > > be per-namespace - i.e. "I want to have <foo> mounted on /usr/barf on
> > > demand and I have no intention to screw somebody else - somebody who
> > > might have the same directory seen as /usr/local/debian/barf and want
> > > <blah> mounted on demand there".
> > 
> > I don't have that intention of mucking someone else up either... But
> > consider: what happens when a namespace is copied? All the automounter
> > directories for autofs/amd/AFS are copied too... With the way I've come up
> > with, this is irrelevant; the in-VFS automount will still work exactly the
> > way it did until it is removed from that namespace. This is the way _I_
> > would expect things to work.
> 
> With your patch automount will happen on every reference to dentry.
> Regardless of the namespace we are in.  

Yes, that is, I think, the correct thing to do... but see also below.

> > I don't see that your argument is a problem... anyone who wants something
> > different in their namespace is going to have to change things anyway.
> 
> And how would they do it?  You get mount triggered by stepping on dentry.
> Period.

I think that's the correct behaviour for an automounter, except for stat(),
which I'd prefer _not_ to cause this (so you can "browse").

> Your kern_automount() will then create a new vfsmount and slap it on the
> tree.  Again, regardless of the namespace we are in / vfsmount we are
> looking at / etc.

Looking at my code, I should probably use the semaphore from the namespace
pointed to by the vfsmount I'm going to be mounting on, just in case we've
managed to cross into someone else's namespace:

	int kern_automount(struct vfsmount *on_mnt, struct dentry *on_dentry)
	{
+		struct namespace *namespace = on_mnt->mnt_namespace;
		struct nameidata nd;
	...
-		down_write(&current->namespace->sem);
+		down_write(&namespace->sem);
	...
-		up_write(&current->namespace->sem);
+		up_write(&namespace->sem);
	...
	}

> I have two namespaces.  One of them has filesystem A mounted on /usr/include.
> Another - on /usr/local/include.  The first one wants /usr/include/foo1 trigger
> mounting B and /usr/include/foo2 trigger mounting C.  The second one wants
> /usr/local/include/foo1 trigger mounting D and /usr/local/include/foo2 not
> trigger anything.
> 
> Namespaces are completely unrelated - I have them set for two different
> users that happen to need some common files, but otherwise have very
> different environments.

Not exactly unrelated. If namespace A derives from namespace B during clone(),
then I would consider B should behave exactly as A until modified - including
automount facilities.

> Could you describe what that "having to change things" would involve?

Well, if you, say, cloned a shell with its own namespace with the intent of 
rearranging its namespace for that user, then I think it would be fair to say
that you'd have to "change things" at some point (ie: use (u)mount to
rearrange the topology).

David