On Tue, 2020-03-03 at 11:32 +0100, Miklos Szeredi wrote:

On Tue, Mar 3, 2020 at 11:22 AM Steven Whitehouse <
swhiteho@redhat.com> wrote:

quoted

Hi,

On 03/03/2020 09:48, Miklos Szeredi wrote:

quoted

On Tue, Mar 3, 2020 at 10:26 AM Miklos Szeredi <miklos@szeredi.hu

quoted

wrote:
On Tue, Mar 3, 2020 at 10:13 AM David Howells <
dhowells@redhat.com> wrote:

quoted

Miklos Szeredi [off-list ref] wrote:

quoted

I'm doing a patch.   Let's see how it fares in the face of
all these
preconceptions.

Don't forget the efficiency criterion.  One reason for going
with fsinfo(2) is
that scanning /proc/mounts when there are a lot of mounts in
the system is
slow (not to mention the global lock that is held during the
read).

BTW, I do feel that there's room for improvement in userspace
code as
well.  Even quite big mount table could be scanned for *changes*
very
efficiently.  l.e. cache previous contents of
/proc/self/mountinfo and
compare with new contents, line-by-line.  Only need to parse the
changed/added/removed lines.

Also it would be pretty easy to throttle the number of updates so
systemd et al. wouldn't hog the system with unnecessary
processing.

Thanks,
Miklos

At least having patches to compare would allow us to look at the
performance here and gain some numbers, which would be helpful to
frame
the discussions. However I'm not seeing how it would be easy to
throttle
updates... they occur at whatever rate they are generated and this
can
be fairly high. Also I'm not sure that I follow how the
notifications
and the dumping of the whole table are synchronized in this case,
either.

What I meant is optimizing current userspace without additional
kernel
infrastructure.   Since currently there's only the monolithic
/proc/self/mountinfo, it's reasonable that if the rate of change is
very high, then we don't re-read this table on every change, only
within a reasonable time limit (e.g. 1s) to provide timely updates.
Re-reading the table on every change would (does?) slow down the
system so that the actual updates would even be slower, so throttling
in this case very much  makes sense.

Optimizing user space is a huge task.

For example, consider this (which is related to a recent upstream
discussion I had):
https://blog.janestreet.com/troubleshooting-systemd-with-systemtap/

Working on improving libmount is really useful but that can't help
with inherently inefficient approaches to keeping info. current
which is actually needed at times.

Once we have per-mount information from the kernel, throttling
updates
probably does not make sense.

And can easily lead to application problems. Throttling will
lead to an inability to have up to date information upon which
application decisions are made.

I don't think it's a viable solution to the separate problem
of a large number of notifications either.

Ian