On 28/11/17 00:01, Mike Marion wrote: > On Thu, Nov 23, 2017 at 08:36:49AM +0800, Ian Kent wrote: > >> And with the move of userspace to use /proc based mount tables (one >> example being the symlink of /etc/mtab into /proc) even modest sized >> direct mount maps will be a problem with every entry getting mounted. >> >> Systems will cope with this fine but larger systems not so much. > > Yes.. we've run into some big issues due to the change of /etc/mtab from > a file to a symlink to /proc/self/mounts. Most have been worked around > thus far (mostly due to Suse coming up with patches) but still have a > few annoying ones. > I think the situation is going to get worse before it gets better. On recent Fedora and kernel, with a large map and heavy mount activity I see: systemd, udisksd, gvfs-udisks2-volume-monitor, gvfsd-trash, gnome-settings-daemon, packagekitd and gnome-shell all go crazy consuming large amounts of CPU. Once the mount activity is completed I see two processes continue to consume a large amount of CPU. I thought one of those two was systemd but my notes say they were gvfs-udisks2-volume-monitor and gnome-settings-daemon. The symlink change was probably the start, now a number of applications now got directly to the proc file system for this information. For large mount tables and many processes accessing the mount table (probably reading the whole thing, either periodically or on change notification) the current system does not scale well at all. Ian -- To unsubscribe from this list: send the line "unsubscribe autofs" in
