==> Regarding [VFS-RFC] autofs4 and bind, rbind and move mount requests; [email protected] adds:
raven> I've been investigating a bug report about bind mounting an autofs
raven> controlled mount point. It is indeed disastrous for autofs. It would
raven> be simple enough it to check and fail silently but that won't give
raven> sensible behavior.
raven> What should the semantics be for these type of mount requests
raven> against autofs?
raven> First, a move mount doesn't make sense as it places the autofs
raven> filesystem in a location that is not specified in the autofs map to
raven> which it belongs. It looks like the user space daemon would loose
raven> contact with the newly mounted filesystem and so it would become
raven> useless and probably not umountable, not to mention how the daemon
raven> would handle it. I believe that this shouldn't be allowed. What do
raven> people think? If we don't treat these as invalid then how should
raven> they behave?
I think it is reasonable to not allow this.
[snip]
raven> Bind mount requests are another question.
raven> In the case of a bind mount we can find ourselves with a dentry in
raven> the bound filesystem that is marked as mounted but can't be followed
raven> because the parent vfsmount is in the source filesystem.
raven> Should the automount functionality go along with the bind mount
raven> filesystem? At this stage there's no straight forward way for autofs
raven> to handle two independent mount trees from the same automount
raven> daemon. It's just not designed to do that.
raven> It's probably possible to make this behave as though the automounted
raven> filesystem is mirrored under the filesystem to which it is
raven> bound. But it's likely problematic. What do people think about this?
raven> I've not really thought enough about recursive bind mounts yet but
raven> on the face of it they look fairly ugly as well.
raven> I know this post is short on detail but hopefully that will come out
raven> if there are people interested in discussing it further.
raven> I look forward to some feedback and hope I can find a realistic
raven> approach to solving this problem.
Yeah, this is really a tricky matter. On the surface, it really doesn't
make sense to me to do a mount -bind with a source directory of the
automount point. Given the current semantics of bind mounts, what does
this gain you? Likely it gains you access to an emtpy directory, or a
directory full of empty directories (in the case of ghosting).
Mount -rbind is equally nonsensical, if you agree with the last paragraph.
You will only get a copy of the vfsmount tree at the time of the mount
-rbind call. Who knows what was mounted at that time, it really isn't
deterministic.
-Jeff
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]