On Sat, Apr 10, 2021 at 09:46:47AM +0800, Ian Kent wrote: > > 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. Yeah, that's pretty much why I never sent the email I wrote up before, I started to realize it was far more complicated as you say. > 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? Yep, that's one of the issues I thought of too. It's already an issue we have with the current logic as well. Usually we end up just tagging the hosts for a reboot once any compute jobs on them are done, it's just easier than fixing them by hand. > 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 ... It'd be great if it could be implemented at some point. -- Mike Marion-Unix SysAdmin/Sr. Staff IT Engineer-http://www.qualcomm.com
