On Tue, 3 Oct 2000, Alexander Viro wrote:
> Nope. Doesn't have to be a symlink - it can be a directory. Overmounted by
> bind-mount - you can mount over a mountpoint.
And do a mount onto it while the kernel is waiting for revalidation? I'm
sorry, but that makes it even more dependent on the kernel internals than
the symlink hack. What if the kernel has already done the mountpoint
crossing at the time it decides to do the revalidation? What if some other
kernel in the future decides to do just that?
There is one other downside: if you overlay it, you can't unmount it
unless you also unmount the filesystem mounted over. Or, one of the key
features of amd is that you can kill it, umount its own mount points
and restart it, without having to unmount the real NFS filesystems mounted
by amd. In most cases you couldn't do that anyway, unless you killed all
the users on the system that were using them.
[the autofs-enabled amd is the exception to the above rule, but that's a
deficiency in the Linux autofs, not in amd. Linux autofs doesn't allow its
mount points to be restarted (taken over by another automount process)]
No, not acceptable.
The future has AUTOFS written in capitals, but for now we'll have to live
with what we have..
> > 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.
See the above. Can't do that, sorry.
> 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).
But they don't. You are overlaying a directory with some other object -- a
symlink in this case. It's a different object in a different filesystem,
so no problem there, and indeed all unix kernels out there (linux included)
handle it just fine. Linux however won't allow you to unmount it.
> 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).
I checked. super.c doesn't make any assumptions about the root of the
filesystem being mounted/umounted. Neither does follow_mount in namei.c,
it simply replaces the covered dentry with the root dentry of the covering
filesystem. lookup_dentry calls follow_mount and _then_ it calls
do_follow_link, and only after that it checks to see if the dentry is a
directory, so we're safe there.
I couldn't find anything in dcache.c, either. These three (namei, dcache
and super.c) are the only that deal with mountpoints, so I think we're
pretty safe.
Alan, what's your opinion on this?
> Again, the right thing for 2.4 is to do bind-mount instead of playing with
> symlinks. As for the autofs plans - ask HPA...
Unless something really dramatic happens in 2.4 (which I doubt at this
point), autofs is not going to be significantly different for what we had
in 2.2, at least from amd's point of view. The only additional feature of
autofs v4 is that it allow us to do host mounts.
Perhaps at some point in the near future I'll write the ioctl support for
both autofs v3 and v4, to allow the take-over of a catatonic autofs
mountpoint. If nobody beats me to it, that is.
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:18 EST