Statsfs: A Proposed Linux File-System For Kernel Statistics

[ssokolow]

/me sees a csh-family shell. Dismisses everything the poster says as the ramblings of a madman.

(Just a joke. I prefer the user experience of sysctl to that of a virtual filesystem too.)

[aht0]

It was fixed. It's called /proc/sys. They're both interfaces to the same thing.

If it was "fixed" then WHY does it has to be re-made, AGAIN??? Wasn't it, like, fixed? Why it has limitations and overhead it has? What was wrong with previous model and why it couldn't be re-made to be backwards-compatible?

If by "sysctl" you mean /usr/bin/sysctl, that is just a wrapper around /proc/sys.
You originally asked:

...which implied you were talking about sysctl(2) (the system call), not sysctl(8) (the program). sysctl(8) has never been deprecated. It was just changed internally to use the new interface.

So you've just been complaining about an implementation detail you shouldn't even care about. This is what people mean when they say "a little learning is a dangerous thing".

Dude, I use sysctl all the time, it's comfortable for adjusting or checking settings on-the-fly and I don't have to fuck around with pseudo-filesystems or even GUI's while doing it. Handling jails (virtualization) ain't an issue either Completely beats me why Linux had to re-design whole concept for itself and still fail with it. Could have solved techical issues under the hood and leave it outwardly same.

[zyxxel]

That's a very niche use case and is something you only do for system introspection and debugging purposes anyway. It's the exception that proves the rule -- the performance of reading stuff in /proc almost never matters and even when it somewhat does, performance is still acceptable.

...But you're shifting the goalposts now anyway. /proc/sys has almost nothing to do with the original procfs stuff, except for sharing a mount point. Literally no one reads the /proc/sys/ tree every 2 seconds like they do with /proc/[0-9]*.

Quite a lot of systems are running monitoring software like netdata. And on more lower-end machines, netdata consumes a lot of CPU power just because there aren't API to call to retrieve the required information. Digging through the /proc file system is really quite time-consuming.

And in this case, we aren't locked into debating the /proc/sys/ subtree. It's about accessing all this juicy system information using text files in a virtual file system, or using a system call and get them back in the original, binary, form.

[bitman]

OK, now tell me how would I retrieve this "stats" info using a shell script that I could write in a couple of minutes if there was only a C API.

I never said that we __only__ need a C api. However that would still be better than __only__ having sysfs like now.
Making a command line app that uses C api to query data and output text makes much more sense than making every C app parse text files over and over and over.

[Larry$ilverstein]

If you look at top-like commands on embedded devices, you would notice the significant percentage CPU they can consume to process /proc/ files. And the file accesses may stand for a factor 2-3 compared to system calls to retrieve the same data.

That's a very niche use case and is something you only do for system introspection and debugging purposes anyway. It's the exception that proves the rule -- the performance of reading stuff in /proc almost never matters and even when it somewhat does, performance is still acceptable.

...But you're shifting the goalposts now anyway. /proc/sys has almost nothing to do with the original procfs stuff, except for sharing a mount point. Literally no one reads the /proc/sys/ tree every 2 seconds like they do with /proc/[0-9]*.

[zyxxel]

Why?



sysctl was removed because /proc/sys was objectively better in every way except number of syscalls required and even that will be improved if the Greg K.H. readfile() syscall gets merged. The performance of reading/writing kernel tunables is irrelevant 99.9% of the time anyway.

You can hand wave and parade your JavaScript dev sensibilities as much as you want, but at the end of the day, every single kernel engineer involved took the opposite view to you.

If you look at top-like commands on embedded devices, you would notice the significant percentage CPU they can consume to process /proc/ files. And the file accesses may stand for a factor 2-3 compared to system calls to retrieve the same data.

open + read + close is rather expensive. Even more if having to handle JSON instead of space-/comma-separated text lines.

[tildearrow]

We need a c api, not another thing text thing that everyone will write parsing functions for over and over.

OK, now tell me how would I retrieve this "stats" info using a shell script that I could write in a couple of minutes if there was only a C API.

[Larry$ilverstein]

If it was "error prone and pointless" maybe it should have been fixed

It was fixed. It's called /proc/sys. They're both interfaces to the same thing.

No I haven't used /proc/sys ...

systcl has been pretty convenient so far.

If by "sysctl" you mean /usr/bin/sysctl, that is just a wrapper around /proc/sys.

You originally asked:

What was wrong with sysctl? It was deprecated in Linux in exchange of what?

...which implied you were talking about sysctl(2) (the system call), not sysctl(8) (the program). sysctl(8) has never been deprecated. It was just changed internally to use the new interface.

So you've just been complaining about an implementation detail you shouldn't even care about. This is what people mean when they say "a little learning is a dangerous thing".

[aht0]

Have you ever used anything in /proc/sys/, like e.g. /proc/sys/vm/drop_caches or /proc/sys/vm/laptop_mode? If so, you've already been using the replacement.

The syscall was error prone and pointless.

If it was "error prone and pointless" maybe it should have been fixed, instead of being re-invented differently x powered n times? Are present options better if they have to be constantly re-made, to nobody's satisfaction?

No I haven't used /proc/sys, its a Linux-specific thing. I was asking about sysctl because when I still used Linux more, it still had it around, at some point I read about it's depreciation and thought "whatever....". Few years later while trying it still seemed to return results. Dunno, maybe the kernel was older in that installation.

systcl has been pretty convenient so far.

[k1e0x]

Why?



sysctl was removed because sysfs was objectively better in every way except number of syscalls required and even that will be improved if the Greg K.H. readfile() syscall gets merged. The performance of reading/writing kernel tunables is irrelevant 99.9% of the time anyway.

You can hand wave and parade your JavaScript dev sensibilities as much as you want, but at the end of the day, every single kernel engineer involved took the opposite view to you.

Oh actually I'm a system admin.. you know your end user and customer. One that is complaining because they have to deal with these nonsensical and painful implementations. You should pay attention to your users because they may not recommend Linux platforms if they find it too hard to work with. Kernel engineers aren't the ones actually deploying and living with this mess.

sysctl is straight forward, I want to get or set system tuneables. Get/Set is a straight forward metaphor and a very common one. It's used in all kinds of things even old BIOS and web forms resemble it. You toggle the value on a page, you don't browse a file structure and edit it.

/proc/sys is like.. wait a min.. so the kernel value.. what parent folder was that in.. why again am I looking in the file system.. ok I'll write that file.. I guess it set? it didn't display any output like sysctl.. better check it with cat. It feels wrong/clumsy to me.