Messages in this thread | | | Subject | Re: [PATCH] VFS autmounter support | Date | Wed, 18 Jun 2003 12:01:07 +0100 | From | 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(¤t->namespace->sem); + down_write(&namespace->sem); ... - up_write(¤t->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 - 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/
| |