On Do, 02.04.20 15:52, Miklos Szeredi (miklos@xxxxxxxxxx) wrote: > > Don't get me wrong, neither the proc nor the fsinfo implementations > > deal with the notification storms that cause much of the problem we > > see now. > > > > IMHO that's a separate and very difficult problem in itself that > > can't even be considered until getting the information efficiently > > is resolved. > > This mount notification storm issue got me thinking. If I understand > correctly, systemd wants mount notifications so that it can do the > desktop pop-up thing. Is that correct? This has little to do with the desktop. Startup scheduling is mostly about figuring out when we can do the next step of startup, and to a big amount this means issuing a mount command of some form, then waiting until it is established, then invoking the next and so on, and when the right mounts are established start the right services that require them and so on. And with today's system complexity with storage daemons and so on this all becomes a complex network of concurrent dependencies. Most mounts are established on behalf of pid 1 itself, for those we could just wait until the mount syscall/command completes (and we do). But there's plenty cases where that's not the case, hence we need to make sure we follow system mount table state as a whole, regardless if its systemd itself that triggers some mount or something else (for example some shell script, udisks, …). > But that doesn't apply to automounts at all. A new mount performed by > automount is uninteresting to to desktops, since it's triggered by > crossing the automount point (i.e. a normal path lookup), not an > external event like inserting a usb stick, etc... systemd does not propagate mount events to desktops. You appear to be thinking about the "udisks" project or so? Lennart -- Lennart Poettering, Berlin
