Re: "statsfs" API design

[Greg KH <gregkh@linuxfoundation.org>]

On Mon, Nov 11, 2019 at 11:40:32PM +0300, Alexey Dobriyan wrote:
> On Sun, Nov 10, 2019 at 09:58:14PM +0100, Paolo Bonzini wrote:
> > On 10/11/19 16:34, Alexey Dobriyan wrote:
> > > In the other direction: describe every field of /proc/*/stat file
> > > without looking to the manpage:
> > > 
> > > $ cat /proc/self/stat
> > > 5349 (cat) R 5342 5349 5342 34826 5349 4210688 91 0 0 0 0 0 0 0 20 0 1 0 864988 9183232 184 18446744073709551615 94352028622848 94352028651936 140733810522864 0 0 0 0 0 0 0 0 0 17 5 0 0 0 0 0 94352030751824 94352030753376 94352060055552 140733810527527 140733810527547 140733810527547 140733810532335 0
> > 
> > That's why this is not what I am proposing, and also not what Greg has
> > mentioned.
> 
> The argument was that text is somehow superior to binary. Experiment shows
> that userspace can make a mess of both modes therefore preferring one
> to another should be based on something else (preferably objective).

No, that was NOT what my argument was.

My argument is that you have to have self-describing data somehow,
otherwise you will always get out of sync with what the kernel is
exporting and what userspace expects.  The above crazy procfs example
proves my point very well :)

sysfs "solves" this problem by requiring one value per file.  If the
file is not present, userspace "knows" that the value isn't there at
all.  It a simple solution for the problem that procfs has with multiple
values in single files and is why we did it that way.

Now that's not to say this is the only way to solve the issue here, it's
just the one that we decided to use at the time.  statfs can choose to
do it differently, but it can NOT just ignore the problem here,
otherwise we end up with the old procfs problems as you show above.

> /proc have these two problems:
> First, noticeably slow:
> 
> 	https://news.ycombinator.com/item?id=21414882

Yes, opening thousands of files is "slow", that's known :)

> Second, overinstantiating inodes and dentries:
> 
> 	https://lore.kernel.org/lkml/20180424022106.16952-1-jeffm@suse.com/

Exporting hundreds of thousands of files, what could go wrong? :)

> statfs maybe never get to that level but it is not hard to see what lies
> at the end of the tunnel.

Those are nice things to think about while doing this, but I think we
are a long ways off from these types of issues.

thanks,

greg k-h