On Fri, 2021-04-09 at 16:42 -0700, Mike Marion wrote: > On Fri, Apr 09, 2021 at 08:50:27AM +0800, Ian Kent wrote: > > > I haven't looked at this case for a very long time but I'm pretty > > sure nesting isn't allowed in direct mount maps (with any map type > > really). I'm also pretty sure I don't test for nesting in direct > > mount maps (quite difficult to do) and fail the trigger mount. > > IME (or "Our" vs "My") I'd reiterate that nesting (as shown) does > NOT > work. In fact, it's a been a huge pain for us over the > years. We've > had to put seatbelts in place to avoid them being created in our > maps > because it can mess with the paths when done or changed. In fact, I > wrote up a long email once to send here and never did, about a > suggest > changes to the logic to help with what we run into often. > > We still have an issue when something happens such as there's a > directory > in the map of: > /prj/foo > and it needs to be broken up to multiple paths, such as; > /prj/foo/bar > /prj/foo/baz > > The problem that arises for us is the people handling the filers and > maps make that change in one fell swoop. So what happens on hosts > already running is the next re-read does logic like: > - I see new paths /prj/foo/bar and /prj/foo/baz and mounts them as > type > autofs > - I see that /prj/foo is gone, I need to umount it.. > and the umount fails with: > do_umount_autofs_direct: ask umount returned busy for /prj/foo I tried this with a couple of different paths, the paths in the example above and another set. In both cases the umount was performed followed by the mount without problem. That doesn't men that this won't happen for other paths or even these paths on some other system, it just means that the procedure to reproduce it can't reliably used. I used direct mounts and assumed you were too, is that right? Anyway, this does imply that a policy on what to do for busy mounts is needed possibly more so than umount/mount ordering enforcement which will be a bit difficult and I would probably want to use code that's not yet in a release. That's because of the annoying ordering of operations (mounts and umounts) that's a continual problem, much more than you would think and much more than it should be. > > and usually requires manual intervention to kick loose nested bits. > > I'd love to see re-reads parse the map, save the new paths, parse the > removals, then add the new paths after removing/umounting removed > paths. Yeah, it isn't quite that simple I think. Ian
