Re: one-line umount patch needed for am-utils

From: Alexander Viro (viro@math.psu.edu)
Date: Tue Oct 03 2000 - 21:45:15 EST


On Tue, 3 Oct 2000, Ion Badulescu wrote:

> On Tue, 3 Oct 2000, Alexander Viro wrote:
>
> > On 2.4 you can do them directly - no intermediate filesystem
> > needed. mount() with MS_BIND in flags will do the thing quite fine
> > (mount(old_dir,new_dir,NULL,MS_BIND,NULL); or mount --bind $old_dir
> > $new_dir; notices that old_dir doesn't have to be a root of any filesystem
> > - any existing directory will be fine). Essentially, that's "symlinks done
> > right".
>
> I know about the bind-mounting, but it doesn't make a significant
> difference in this case. There is still a need for a "trigger" symlink
> that causes amd to mount the remote filesystem.

Nope. Doesn't have to be a symlink - it can be a directory. Overmounted by
bind-mount - you can mount over a mountpoint.

> Autofs is a totally different thing, and am-utils-6.1 does support autofs,
> and it will also support bind-mounting on linux-2.4. However, autofs
> doesn't support direct mounts, at least for the time being.

> > > It's kind of silly and an abuse of the VFS, I agree. Unfortunately, it's
> > > been around for a while, it works on other systems and real people are
> > > using it. And they get a nasty surprise when they try it on Linux: the
> > > amd-provided NFS filesystems cannot be unmounted, because the VFS umount
> > > code follows the root symlink.
> >
> > So fix amd and teach it not to do that.
>
> Can't do that. As I said, there are real people using this feature out
> there, it cannot be removed. I know what you're thinking, emulate direct
> mounts using indirect mounts (and/or autofs). It's possible, but not
> without system administrator support, because amd then needs a third
> directory in the namespace to support the indirect mounts, whose name has
> not been provided and which cannot simply appear out of the blue.

Indeed it doesn't. Replace symlinks with directories and make
e.g. revalidation to trigger mount --bind.

> Besides, amd issues aside, can you point to something in the NFS spec that
> says such a filesystem is illegal? If not, than the current Linux behavior
> is buggy, because it allow mounting a filesystem which cannot then be
> unmounted.

Oh, that I agree with - we probably shouldn't allow such mounts in the
first place (non-directories and directories shouldn't turn into each
other).

> > Last time I've touched 2.2 VFS was long ago. And 2.4 doesn't need that -
> > there's much better mechanism for the same thing. E.g. you get correct
> > behaviour of ".." in the root of bound subtree - it goes to parent
> > of new_dir, instead of the parent of old_dir (as it would be with
> > symlinks). See below:
> [example trimmed]
>
> I fail to see how this is relevant to the problem at hand.. maybe I'm just
> dense, please enlighten me. :-)

Umm... Works as symlink minus several bogus details associated with the
latter?

> Don't forget that linux 2.2 is the proposed beneficiary of the patch..
> So, to get back on-topic, can you think of a case when doing
> lnamei() instead of namei() on the mountpoint could break things?

Not much - I'ld check do_follow_mount() and neighbors, though (watch for
assumptions re directory vs. non-directory in the lookup_dentry() and
other places using ->d_covers/->d_mounts).

Again, the right thing for 2.4 is to do bind-mount instead of playing with
symlinks. As for the autofs plans - ask HPA...

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/



This archive was generated by hypermail 2b29 : Sat Oct 07 2000 - 21:00:13 EST