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 ...
This takes things a bit further than I had.
May I ask, what was the motivation for adding this?
As the commit message hints, I have a customer with a work-flow that
involves moving mount out of the automount tree with "mount -M ....".
This used to work perfectly in out SLE-11 product which didn't use
systemd and so followed the kernel default that mounts were "private" by
default. "mount -M" only works out of parents that are private.
Haha, but it's worse than that.
What about systemd's PrivateTmp (I think that's spelling) which creates
a new mount namespace for temporary files. Think about what happens if
you restart a service which this setting when there are autofs mounts
present. Maybe someone made some changes because I haven't seen problems
of this nature for a while but at one time the autofs mounts propagated
to the temp files mount namespace and could never expire preventing them
from ever being umounted including those in the init mount namespace.
I think there's also systemd-nspawn that might have similar problems.
Anyway, it's not very fun, so what your doing is useful, !!
But with SLE-12 we use systemd, and systemd sets everything to "shared"
by default. There are good reasons for this and the customer doesn't
want to over-ride it globally. They just want the autofs mounts to not
be shared, so that mount -M works.
Don't ask me why they want to move mounts like this - but it doesn't
seem an unreasonable thing to want.
I'm not sure how useful this would be, autofs is very much path based
due to it being driven by path based maps (as you know).
Mind you it sounds a bit like how automounts can work in containers.
Essentially you bind mount (eg. docker --volume=<path> option, IIRC)
the autofs mount into the container at start and child mounts get
propagated to the container. The paths just need to be the same inside
the container.
Ian
