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 .... ?? I cannot imaging how that would work. Or maybe you mean multimounts? > > they are distinct mounts, is that the case here? 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 ? > > > > > > 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. > > > > > 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... > > It sounds like the goal is to set the autofs mount propagation > > private, is that right? Yes. > > > 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. 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. 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. Thanks, NeilBrown
