Re: [RFC PATCH] getvalues(2) prototype

Miklos Szeredi [off-list ref] writes:

On Wed, 23 Mar 2022 at 23:20, Theodore Ts'o [off-list ref] wrote:

quoted

On Wed, Mar 23, 2022 at 02:24:40PM +0100, Miklos Szeredi wrote:

quoted

The reason I stated thinking about this is that Amir wanted a per-sb
iostat interface and dumped it into /proc/PID/mountstats.  And that is
definitely not the right way to go about this.

So we could add a statfsx() and start filling in new stuff, and that's
what Linus suggested.  But then we might need to add stuff that is not
representable in a flat structure (like for example the stuff that
nfs_show_stats does) and that again needs new infrastructure.

Another example is task info in /proc.  Utilities are doing a crazy
number of syscalls to get trivial information.  Why don't we have a
procx(2) syscall?  I guess because lots of that is difficult to
represent in a flat structure.  Just take the lsof example: tt's doing
hundreds of thousands of syscalls on a desktop computer with just a
few hundred processes.

I'm still a bit puzzled about the reason for getvalues(2) beyond,
"reduce the number of system calls".  Is this a performance argument?

One argument that can't be worked around without batchingis atomicity.
Not sure how important that is, but IIRC it was one of the
requirements relating to the proposed fsinfo syscall, which this API
is meant to supersede.   Performance was also oft repeated regarding
the fsinfo API, but I'm less bought into that.

A silly question.  Have you looked to see if you can perform this work
with io_uring?

I know io_uring does all of the batching already, so I think io_uring is
as ready as anything is to solve the performance issues, and the general
small file problem.  There is also the bpf information extractor (Sorry
I forget what it's proper name is) that also can solve many of the small
read problems.

I am very confused you mention atomicity but I don't see any new
filesystem hooks or anyway you could implement atomicity for reads
much less writes in the patch you posted.

If the real target is something like fsinfo that is returning
information that is not currently available except by possibly
processing /proc/self/mountinfo perhaps a more targeted name would
help.

I certainly did not get the impression when skimming your introduction
to this that you were trying to solve anything except reading a number
of small files.

Eric