On Wed, 23 Mar 2022 at 12:43, Christian Brauner <brauner@xxxxxxxxxx> wrote: > Yes, we really need a way to query for various fs information. I'm a bit > torn about the details of this interface though. I would really like if > we had interfaces that are really easy to use from userspace comparable > to statx for example. 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. So I'm trying to look beyond fsinfo and about how we could better retrieve attributes, statistics, small bits and pieces within a unified framework. The ease of use argument does not really come into the picture here, because (unlike stat and friends) most of this info is specialized and will be either consumed by libraries, specialized utilities (util-linux, procos) or with a generic utility application that can query any information about anything that is exported through such an interface. That applies to plain stat(2) as well: most users will not switch to statx() simply because that's too generic. And that's fine, for info as common as struct stat a syscall is warranted. If the info is more specialized, then I think a truly generic interface is a much better choice. > I know having this generic as possible was the > goal but I'm just a bit uneasy with such interfaces. They become > cumbersome to use in userspace. I'm not sure if the data: part for > example should be in this at all. That seems a bit out of place to me. Good point, reduction of scope may help. > Would it be really that bad if we added multiple syscalls for different > types of info? For example, querying mount information could reasonably > be a more focussed separate system call allowing to retrieve detailed > mount propagation info, flags, idmappings and so on. Prior approaches to > solve this in a completely generic way have gotten us not very far too > so I'm a bit worried about this aspect too. And I fear that this will just result in more and more ad-hoc interfaces being added, because a new feature didn't quite fit the old API. You can see the history of this happening all over the place with multiple new syscall versions being added as the old one turns out to be not generic enough. I think a new interface needs to - be uniform (a single utility can be used to retrieve various attributes and statistics, contrast this with e.g. stat(1), getfattr(1), lsattr(1) not to mention various fs specific tools). - have a hierarchical namespace (the unix path lookup is an example of this that stood the test of time) - allow retrieving arbitrary text or binary data And whatever form it takes, I'm sure it will be easier to use than the mess we currently have in various interfaces like the mount or process stats. Thanks, Miklos
