Re: do_mount_autofs_direct: failed to create mount directory ...

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


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:
and it needs to be broken up to multiple paths, such as;

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

[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