On Wed, Mar 23, 2022 at 02:24:40PM +0100, Miklos Szeredi wrote: > 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. This has been proposed in the past a few times. Most recently by the KVM developers, which tried to create a "generic" api, but ended up just making something to work for KVM as they got tired of people ignoring their more intrusive patch sets. See virt/kvm/binary_stats.c for what they ended up with, and perhaps you can just use that same type of interface here as well? thanks, greg k-h
