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 > > 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. It sounds simple to do but I think you would be surprised with the sort of difficulties I would encounter. But, if that was done, what would be the policy if /prj/foo was in use, lazy umount /prj/foo mounts, ignore all changes at or below /prj/foo until it's no longer in use, or something else? I would be tempted to lazy umount things at or below /prj/foo, after all they would be using stale paths and will eventually end up in tears anyway, particularly if processes have open file handles on paths within the mount. Don't get me wrong, this does sound sensible and is something that needs to be fixed, there's just those cases that cause me pain time and time again that get in the road. The other problem is I might use features that are as yet unreleased (but in the current source tree) so that would complicate matters, OTOH I might not need the new features and, other than the in use policy, it might straight froward ... Ian
