Re: [PATCH] VFS autmounter support

[David Howells <dhowells@warthog.cambridge.redhat.com>]

Hi Al,

> > I don't think this is evil, but it looks a bit non-appropriate for now. 
> > But I'd like to see Al's (and others) comments on it..
> 
> I'm not too happy with it.  If nothing else, IMO it's the wrong way to
> solve the problem - if you want a bunch of filesystems look like a
> single object (i.e. go together wherever we mount it, etc.), make it
> a filesystem.  That would make a lot of sense, and not only for AFS.

But I don't want them to look like a single object...

If I did, I could do AFS entirely inside one superblock. What I want is for
each AFS volume to be represented by its own superblock - and for the
differences to be visible from userspace. This also means that I can use AFS
vnode numbers directly as VFS inode numbers.

Furthermore, doing it this way means that if multiple instances of a volume
get mounted for some reason (maybe in different namespaces, or maybe by
multiple mountpoints referring to the same volume), they can share inode and
dentry records.

Layering another filesystem over the top (and doing the actual automount in a
private namespace for example) incurs certain "problems":

 (*) rename (and to a lesser extent, link) are not trivial

 (*) it hides the joins from userspace - which may not be what you want

 (*) it may exhibit distinct files of the same inode and device numbers

 (*) it adds a layer of indirection to every operation

 (*) every "file" you want to access requires an extra inode and dentry

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

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.

I think the default behaviour should be that a clone of a namespace will
behave exactly like the original would at the point it was copied, though
changes in the clone will not reflect on the original and vice-versa (as
should be the case with my patch).

> Namespace is controled by owner of that namespace.  It is a security
> boundary, among other things.  And events in one namespace should not
> cause mounts in another.

Which they don't (or, at least, shouldn't) with my patch...

> Yes, AFS wants an illusion of single filesystem composed in fixed way from
> many pieces.  But if you want to do that, do it right - make sure that it
> acts as a single chunk in mount tree.  IOW, make it look like a single
> filesystem.

As I said above, if I wanted AFS to appear as a single object, there's a lot
easier way of doing it - without touching the VFS at all.

However, mounting each volume separately gives several advantages:

 (1) vnode numbers map directly to inode numbers, without inducing confusion

 (2) rename() and link() get free checks and controls from the VFS

 (3) "find -xdev" can be used to limit a search to a single volume

 (4) the contents of a volume can easily and cheaply be reused for other
     appearances in the same or a different vfsmount topology

David