lkml.org 
[lkml]   [2003]   [Jun]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [PATCH] VFS autmounter support
Date
From

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

\
 
 \ /
  Last update: 2005-03-22 13:36    [W:0.048 / U:0.344 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site