Mount Notification Support Still Coming Together For The Linux Kernel

[starshipeleven]

This can be done through inotify support over /proc/mounts or /proc/self/mountinfo.

why making a dedicated system call when we can rube goldberg our way around it

[markg85]

I'm not assuming anything. I have DONE this, as have most of the other posters in this thread.


No it wouldn't. You're the only person suggesting that polling like that is somehow a sane way to do this. (Aside from Michael in the article, which I assume is from the RH justification rather than his personal opinion).

I'm not saying there's absolutely no valid use case for this - but I AM saying that I've yet to see what it is, and your suggestion isn't it. Though maybe one will come to someone at some point after coffee.

I might or might not be wrong.
So i did a little digging in this mount monitoring stuff from a KDE side.

First you have Solid. It does nothing specifically for mount monitoring itself. It uses udisks2 (at this point it's desktop independent).
Udisks2 does the monitoring (see udisksmountmonitor.c, the function udisks_mount_monitor_constructed). It monitors /proc/self/mountinfo.
But... Does this via glib. Via g_io_channel_new_file. So we dive deeper still.
In glib i do see (in it's folder structure) stuff for inotify and fsnotify (among others). But in code i quickly lose track of where g_io_channel_new_file is actually being executed and which backend it uses.

if the glib part does mount monitoring via inotify then yes, i too see no huge benefit of the new syscall. But i do still see a big benefit of it.
The new syscall (if you've read the source you would've known..) tells you exactly what changed. Which mountpoint got added/removed.
If you use inotify (or polling) you're left to still parse the content of that file. You still have to maintain a list of what it _was_ to what it _became_ to identify what changed and act upon that.

So still, there is a big benefit in having this new mechanism. Granted, the push vs poll isn't the biggest argument i have anymore as inotify can indeed help out there.
The real improvement is that you can basically drop the bookkeeping and use the new syscall for mount changes and act upon that which is imho a very nice and welcome improvement.

The downside here is.. You still have to parse that file once to know the initial state of mount points.
Thus you end up having both mechanisms. Parsing the mount file (initially) and the syscall for subsequent changes.

[arQon]

Thanks for all the digging there!

I really don't remember the details after all this time, and I don't have access to the code any more, but I do remember I felt it was absolutely trivial back then.
Based on your analysis, that opinion doesn't really change: by the time you're parsing things more than zero times in the first place, delta-ing them is such a tiny amount of code/RAM/etc that I might well be tempted to do that anyway rather than add a second way of getting to the same endpoint. It may be even easier code, but it's still MORE code.

So yeah, I think we ARE back where we came in - it looks like it's mostly just spoonfeeding for GNOME. But that's okay. They need all the help they can get, and as long as there's SOME value to it maybe it'll be helpful for someone else someday too.