On 22/3/23 10:52, NeilBrown wrote:
On Wed, 22 Mar 2023, Ian Kent wrote:
On 20/3/23 11:26, NeilBrown wrote:
[[This is a different approach to meeting my customer's need.
Thoughts? - thanks.]]
I'm a bit lost here now.
Sometimes it is useful for an autofs mount to be "private" for mount
propagation. For example, this allows submounts to be moved off with
"mount --move" - such movement is not permitted for shared mounts.
I always use "submount" to refer to map entries that have fstype=autofs,
Now I'm lost.
Do you mean a map containing something like
key -fstype autofs ....
Hehe, no ...
?? I cannot imaging how that would work.
Or maybe you mean multimounts?
Again, no ...
Check out these examples from the connectathon test I use, obviously
those, AUTOMAP_DIR, SERVER1, AUTO_SERVER_DIR, get replaced as part
of the test run:
#
# basic tests
#
g1 -fstype=autofs :AUTOMAP_DIR/auto_icthon
g1a -fstype=autofs / :AUTOMAP_DIR/auto_icthon
g1b / -fstype=autofs :AUTOMAP_DIR/auto_icthon
##
## subdir support
##
g2 \
/s1 -fstype=autofs :AUTOMAP_DIR/auto_icthon \
/s2 -fstype=autofs :AUTOMAP_DIR/auto_icthon
g2a \
/ SERVER1:AUTO_SERVER_DIR/export5/testing/test \
/s1 -fstype=autofs :AUTOMAP_DIR/auto_icthon \
/s2 -fstype=autofs :AUTOMAP_DIR/auto_icthon
g3b SERVER1:AUTO_SERVER_DIR/export5/testing/test \
/s1 -fstype=autofs :AUTOMAP_DIR/auto_icthon \
/s2 -fstype=autofs :AUTOMAP_DIR/auto_icthon
g3c \
/ SERVER1:AUTO_SERVER_DIR/export5/testing/test \
/s1 SERVER1:AUTO_SERVER_DIR/export5/testing/test/s1 \
/s2 SERVER1:AUTO_SERVER_DIR/export5/testing/test/s2 \
/s1/ss1 -fstype=autofs :AUTOMAP_DIR/auto_icthon \
/s2/ss2 -fstype=autofs :AUTOMAP_DIR/auto_icthon
##
## subdir-option support
##
g4 -fstype=autofs \
/s1 :AUTOMAP_DIR/auto_icthon \
/s2 :AUTOMAP_DIR/auto_icthon
g4a -fstype=autofs \
/ :AUTOMAP_DIR/auto_icthon
g4b -fstype=autofs / -fstype=nfs
SERVER1:AUTO_SERVER_DIR/export5/testing/test \
/s1 :AUTOMAP_DIR/auto_icthon \
/s2 :AUTOMAP_DIR/auto_icthon
The thing to notice is that a map can be specified for an autofs sub-mount
within the multi-mount tree.
The important thing is that an autofs sub-mount is an independent (autofs)
mount.
they are distinct mounts, is that the case here?
Sounds like that isn't the case here ... these sound like plain
indirect mounts.
No. By "submount" I mean whatever gets automatically mounted onto an
autofs directory. That mount is subordinate to the autofs directory and
below the autofs mount.... Isn't naming fun ?
Indeed it is .. I just call these mounts or triggered mounts if I need
to.
Changing the autofs mount point to "private" with "mount --make-private"
after the automount daemon has started can be problematic. If the
mount point is already shared there will be another copy that will never
get acted on by automount and so tools accessing it can hang.
Right, I get that.
It has occurred to me that this could get addressed in the kernel
instead.
I haven't worked through all the details, but if autofs_d_automount is
called is called with a vfsmnt that is in a different share group to the
one used when the mount was created, then I think it should return an
error, or at least return NULL.
Mmm share groups are confusing to me, I'm pretty sure I don't understand
them. But, from what I have seen of them, the assertion your making sounds
right.
So to safely achieve non-shared auto-mountpoints we need to create a
transparent bind mount at the mount point, mark it as private, then
mount the autofs mount there.
Yes, it's the parent mount that things need to be done to, was always
a bit of a pain to understand IMHO, and easy to get confused by.
So what do we end up with here, a stack of mounts with one extra
mount?
Correct. Is doubling the number of mount points a big cost I wonder...
Well, maybe, the effort David Howells, et. al. (including myself), made
was in part meant to resolve the problems we had with handling very
large mount tables.
You might remember them, they were ultimately rejected by Linus.
An example of the sort of problem we would see is a few systemd
processes consuming around 80% or more CPU because systemd will
respond to mount table chnages when there was mount activity.
There were quite a few customer bugs because of it, either the
piecemeal changes done over time helped or our customer gave up.
So the question of "is having a large number of mounts a problem"
is very much a maybe.
At least it's worth keeping it in mind (and we know users will do
dumb things and expect us to support them/make them work) but also
remembering that it's user buy-in controlled by an option.
It sounds like the goal is to set the autofs mount propagation
private, is that right?
Yes.
And we need to deal with the annoyance of needing to have a parent
mount to propagate from (while at the same time not interfering
with other mounts below it). That was always the thing that caused
me pain and it seemed like an odd and inconvenient design to me.
I'm not sure but this might cause some trouble for the kernel.
I've been working on fixing the expire check for mount trees to
work for multiple mount namespaces in the kernel and mount stacking
topology looks a bit odd.
Do these mount points continue to expire as they should?
I wonder what this will do to my expire changes ...
I'm sorry, I feel like I'm being difficult now and I don't want
to be but what's being done here is puzzling me and sounds just
a bit unusual.
You seem helpful to me, rather than difficult. I realise that what I'm
trying a bit odd and it would need a good justification and a clear lack
of alternatives. I'm not sure yet so there is no reason you should be.
Haha, you have certainly picked a difficult problem.
Mount namespaces and propagation are, IMO, difficult to grok, to
say the least.
I'm glad I'm not coming across as difficult, ;)
I'm actually hoping that I can convince the customer to solve the
problem internally (maybe by specifying one or two private bind mounts
in /etc/fstab if there are any suitable common roots for all their
thousands of mounts) and at the same time exploring options for changing
automount. Leave it with me for now - I'll get back to you after I've
done more exploration and heard back from the customer.
You could add a directory to the master map mount point path and
set it propagation private then mount the autofs mount in there.
No-one will want to make that sort of change though, likely will
have numerous references to the existing path ... etc.
BTW, is there a reason that you don't publish all your current work,
possibly some in a "testing" branch or similar? It might help me to see
where you are headed.
There's no reason not to, mostly there's no reason to do so either.
But I could publish a snapshot of what I have if that will help you.
You would need to remember that often it would be out of date almost
immediately, ;)
We would need two git repos, one the the user space changes, and one
for the kernel expire changes.
The later would be interesting as it starts with a patch from Al that
stops child mounts taking a reference to their parent. That makes the
autofs busyness check very straight forward.
Ian
