Re: [PATCH] VFS autmounter support

[David Howells]

> Namespaces have all kinds of problems anyway when mixed with
> automounting (it's not at all clear what the semantics should be, and
> I'm pretty sure that the semantics the current namespaces give are
> overall undersirable), but when I discussed this issue with Al Viro he
> indicated that you can always access all namespaces via procfs; if not,
> you *should* be able to...

You can't - at the moment anyway - necessarily access an entire
namespace... chroot, for example, may exclude part of it. This, however, may
not be a problem, except for fchdir might be able to put the current working
directory outside of your current root tree:

	fd = open("/afs/.cambridge.redhat.com",O_DIRECTORY);
	chdir("/sillyroot/");
	chroot("/sillyroot/");
	fchdir(fd);
	chdir("afsdoc");  <-- automount required

With my patch, this should just work because the VFS knows exactly where the
automount needs to be done, and merely requires a raw vfsmount struct to be
supplied by the filesystem.

> > Whatever happens, stat() must _not_ cause the automount point to mount.
> > 
> 
> That's actually not true.  It's lstat() that mustn't cause the automount
> point to mount -- stat() only comes into play if lstat() resolves to a
> symlink.  However, lstat() never invokes follow_link, so creating a
> dentry with a follow_link method resolving to itself, and an associated
> dummy directory inode, does what's required.

That _is_ actually true. Doing "ls -l" in that directory would otherwise cause
a mount storm.

follow_link resolving to itself? Surely that'll cause ELOOP very quickly? And
where does this "dummy directory inode" live?

> > 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.
> 
> I mean inside d_revalidate().

You can't do the mount inside d_revalidate(). You don't have enough
information.

> I don't see that it should be handed specially.

But it is special. It's a fs future if you will. If it's done at VFS level it
can be done a lot cleaner.

> >>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.
> 
> Not good enough.  You need to be able to tell that atomically for a full
> *tree*, that can contain multiple mounts, some of which have other
> mounts on top of them, not just for a single superblock.

_Why_ do I need to do that?

I currently degrade a tree from the leaves inwards, true, but the fact that
each layer then needs to wait for expiry can be improved.

I don't expire branches in the tree because the leaves and branches depending
from them pin them by way of their usage counts.

One thing I can't do is a tree unmount, but then we can't do that anyway:

	[root@host135 root]# df /home
	Filesystem           1k-blocks      Used Available Use% Mounted on
	automount(pid902)            0         0         0   -  /home
	[root@host135 root]# ls /home/
	[root@host135 root]# ls /home/dhowells/
	...
	[root@host135 root]# ls /home/
	dhowells
	[root@host135 root]# umount /home
	umount: /home: device is busy

umount can, perhaps, be made to try to do this by trying to rid the tree of
unused automount points, until either it finds something that is in use or is
not a mountpoint, or it manages to completely clear the subtree.

Unused leaves can be determined by checking mnt_count under the dcache lock -
if the count is 1, then the leaf can be removed.

> >>b) how to detect partial unmounts. 
> > 
> > What do you mean by a partial unmount?
> 
> /foo/bar is an automounted filesystem, which has /foo/bar/baz mounted on
> top of it.  Now the user manually umounts /foo/bar/baz (because of
> staleness, or whatever.)  Now the automount system needs to detect
> accesses to /foo/bar/baz and remount... effectively, /foo/bar/baz needs
> to atomically turn into an automounter point.

Yes... it does that. The dentry from the underlying filesystem is still there,
and resurfaces after the umount; and _that_ dentry is what marks this an
automount point (by virtue of its d_automount operation). So this is not a
problem.

David