Messages in this thread | | | From | Jeff Moyer <> | Date | Tue, 24 May 2005 12:28:13 -0400 | Subject | Re: [VFS-RFC] autofs4 and bind, rbind and move mount requests |
| |
==> Regarding [VFS-RFC] autofs4 and bind, rbind and move mount requests; raven@themaw.net 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 majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |