Re: [PATCH] autofs-5.1.8 - add "unshared" option to disable mount propagation.

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]


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)


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


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
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


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

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?

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.


[Index of Archives]     [Linux Filesystem Development]     [Linux Ext4]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux