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.
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.
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.
> 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. :-)
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?
Thanks,
Ion
--
It is better to keep your mouth shut and be thought a fool,
than to open it and remove all doubt.
-
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