On 13/3/23 11:26, NeilBrown wrote:
On Sat, 11 Mar 2023, Ian Kent wrote:
On 11/3/23 14:26, Ian Kent wrote:
On 9/3/23 17:23, NeilBrown wrote:
On Thu, 09 Mar 2023, Ian Kent wrote:
On 8/3/23 13:52, NeilBrown wrote:
New flags in the master map:
autofsshared
autofsprivate
autofsslave
cause the corresponding mount propagation flags to be set on the
autofs
mount point. If none are specified the current behaviour of
inheriting
from the parent unchanged.
For example specify "autofsprivate" allows mount points to be moved
away from autofs using "mount -M .....". This is not supported by the
kernel for the normal default of "shared".
Better flag names should be chosen. I would have liked to use
"shared",
"private", and "slave", but they are already in use and only affect
bind
mounts.
Looks fine, I'll add it to my patch queue, can't say when I'll commit
them though. If you need it committed sooner let me know.
No rush at all - that fact that you don't hate it is enough for now.
I was hoping you *would* hate the flag names I chose and would suggest
something better.
I think your suggesting merging this with the existing code, that's were
I was going too.
After pondering some more the best I can think of is
private-autofs
etc.
Can you think of anything better?
maybe
private=autofs
which could later be extended to a list of filesystem types...
My other thought is that if they autofs mount is "private" then that is
inherited to all descendants including the "bind" mounts. So if we
changed "private" to apply to the autofs mounts rather than just the
bind mounts, then it would still affect the bind mounts as documented,
but it would affect more as well.... I guess that would end up
negatively affecting someone though...
I can't remember now the motivation for what I originally did.
I'll need to look at that but I suspect it's similar, if not
the same, as your reasons for needing it. I should get a bit
of time soon to have a look ...
It looks like the only thing to worry about if we decide to merge
the existing propagation options and these is whether we check
and stop people from shooting themselves in the foot by causing
a deadlock and working out if there are other cases of deadlock
beside bind mounting.
I'm not sure that I understand the cause of the deadlock.
It's been a while but IIRC it was because of mounts that were
propagation shared.
They were propagating to another mount but were also being
propagated back which was strange. Again, IIRC and I'm not sure
I do, when a mount was triggered it was causing the propagation
(back) to cover original mount and trying to follow it triggered
another mount that couldn't be competed (since the first couldn't
be completed). It was odd and I'm pretty sure it shouldn't have
been happening.
Fact is it was hard to understand what was going on in the first
place, but one thing is sure, propagation shared is not friendly
for automounting and is probably a bad choice for the root file
system on systemd's part.
I assume it happens when an autofs mount appears somewhere that the
automount daemon doesn't know about, and when propagation is configured
so that when automount mounts something on the location it *does* know
about, the mount isn't propagated to the problem location.
Tbh, I can't remember now.
And access of that problem location would then block waiting for the
automount daemon to mount something, but it never will.
Is that correct? Is that the only problem?
I think the only autofs problem is mounts can be set propagation shared.
So if automount bind-mounts something from elsewhere over an autofs
mount point, it doesn't want any autofs mount points is mounts below
this to be propagated back to the origin. This is why it defaults to
"slave". That makes sense. It would be safe for mounts to propagate
back only of the original mount was shared or slave - be we cannot check
or enforce that.
I don't think there is any autofs case where a mount should be set
propagation shared. I am talking about autofs mounts themselves
though not the things autofs mounts for us.
Though if the first autofs mount point were already private, then it
should probably leave the child bind-mount as private rather than change
it to slave.
Yes, I agree.
It feels like there is a lot of potential for problems if someone
creates a bind mount from an automount-manager tree and makes it
private, or if the original tree is private. So maybe we shouldn't
support "private" autofs mounts. They should be shared, slave, or
unbindable.
I don't think we should allow autofs mounts to be set propagation
shared, if someone wants to do this they probably don't actually
need to do it and will very likely see a mount hang.
Not sure about private usage, in fact I don't think I care either
way. Thing is users might get themselves into odd situations but
I don't think it will lead to problems bleeding into other mount
trees like we see with shared mount trees.
Clearly binding a private tree elsewhere is going to leave a tree
of mounts that will need to be umounted manually unless it is within
a new mount namespace.
The use case for bind mounting autofs mounts (well what I mean is
actually mount namespace creation but it sounds like and looks like
bind mounting when talking about containers) is into containers where
they need to have the same path to work and need to be propagation
slave for the child directories or mount point triggers that cause
automounts to trigger that then propagate to the namespace.
Similarly slave autofs mounts would be a problem as if they are
bind-mounted to somewhere (or just duplicated into a new namespace).
Changes made by automount wouldn't propagate elsewhere and so deadlocks
could happen.
I think we do need to distinguish between bind-mounting and mount namespace
creation. I've previously used these interchangeably which is not right.
Propagated mounts (I think) are cloned not bound (hehe, sounds like a
bind mount).
Straight bind-mounting generally isn't useful. I'm not sure it should be
prevented since it's usually not harmful although also not useful. Mount
namespace creation should prevent propagation shared autofs mounts being
included, and there should be some way to prevent any autofs mounts (trees)
from being included, and only specifically requested mounts should be cloned
to the target namespace.
But that's kindof a "never ever do this, but allow it if someone says
please"
type thing, and I don't know how to do that, ;)
So maybe the autofs mounts should always be either shared or unbindable.
I agree with that.
Not sure we care about unbindable since pure bind mounts should not cause
harmful side effects but they aren't useful either so ... it's an open
question.
When autofs mounts a new filesystem on an autofs mount it can safely
inherit from the parent. However when it bind-mounts an existing
filesystem it needs to ensure it is at most "slave".
So I can see two sensible options.
1/ The autofs mount is "shared" if parent is shared, and is
unbindable otherwise.
bind-mounts are "slave" if the parent is shared, or
unbindable otherwise
I think it's only necessary to over-ride setting the mount propagation
shared, I don't think there's a use case for shared at all. I may be
wrong ... time will tell.
2/ Everything is unbindable. This could be achieved with the "private"
option.
I must admit I found unbindable behavior odd.
I played with it a bit and probably need to do so again.
IIRC I thought it wasn't usable to prevent bind mounting.
I guess that we still need to support "shared" with leaves bind mounts
as shared, but with a warning that deadlocks can occur if used
carelessly.
Haha, did I say I really don't like propagation shared mounts ... just
in case, I don't like mount that are propagation shared, ;)
Ian
