Messages in this thread |  | | Date | Thu, 5 Oct 2000 19:28:18 -0700 (PDT) | From | Ion Badulescu <> | Subject | Re: one-line umount patch needed for am-utils |
| |
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/
|  |