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. -- Mike Marion-Unix SysAdmin/Sr. Staff IT Engineer-http://www.qualcomm.com
