On Wed, 2020-02-26 at 10:11 +0100, Miklos Szeredi wrote: > On Tue, Feb 25, 2020 at 4:29 PM James Bottomley > <James.Bottomley@xxxxxxxxxxxxxxxxxxxxx> wrote: > > > The other thing a file descriptor does that sysfs doesn't is that > > it > > solves the information leak: if I'm in a mount namespace that has > > no > > access to certain mounts, I can't fspick them and thus I can't see > > the > > information. By default, with sysfs I can. > > That's true, but procfs/sysfs has to deal with various namespacing > issues anyway. If this is just about hiding a number of entries, > then > I don't think that's going to be a big deal. I didn't see name space considerations in sysfs when I was looking at it recently. Obeying name space requirements is likely a lot of work in sysfs. > > The syscall API is efficient: single syscall per query instead of > several, no parsing necessary. > > However, it is difficult to extend, because the ABI must be updated, > possibly libc and util-linux also, so that scripts can also consume > the new parameter. With the sysfs approach only the kernel needs to > be updated, and possibly only the filesystem code, not even the VFS. > > So I think the question comes down to: do we need a highly efficient > way to query the superblock parameters all at once, or not? Or a similar question could be, how could a sysfs interface work to provide mount information. Getting information about all mounts might not be too bad but the sysfs directory structure that would be needed to represent all system mounts (without considering name spaces) would likely result in somewhat busy user space code. For example, given a path, and the path is all I know, how do I get mount information? Ignoring possible multiple mounts on a mount point, call fsinfo() with the path and get the id (the path walk is low overhead) to use with fsinfo() to get the all the info I need ... done. Again, ignoring possible multiple mounts on a mount point, and assuming there is a sysfs tree enumerating all the system mounts. I could open <sysfs base> + mount point path followed buy opening and reading the individual attribute files ... a bit more busy that one ... particularly if I need to do it for several thousand mounts. Then there's the code that would need to be added to maintain the various views in the sysfs tree, which can't be restricted only to the VFS because there's file system specific info needed too (the maintain a table idea), and that's before considering name space handling changes to sysfs. At the least the question of "do we need a highly efficient way to query the superblock parameters all at once" needs to be extended to include mount table enumeration as well as getting the info. But this is just me thinking about mount table handling and the quite significant problem we now have with user space scanning the proc mount tables to get this information. Ian
