Extending statx()

When Andreas Dilger proposed the statx() topic for the 2017 Linux Storage, Filesystem, and Memory-Management Summit, the system call had still not been merged. But that all changed in the 4.11 development cycle when Al Viro merged the system call to provide additional file information. So, unlike previous years, the discussion was not about how to merge such a system call but, instead, how to extend statx() for additional file information.

Both Dilger and David Howells (who authored the statx() patches) led the discussion. Dilger noted that the lack of statx() has been a pain point for him; for example, ls tries to stat() every file in order to properly color it in its output. But stat() is painful on network filesystems and often the kernel already has the information needed, so no network round-trip is needed. statx() solves that problem.

The core of the system call was merged; now ext4, Gluster, and others have support. Due to bikeshedding, Dilger said, the core has been pared back several times over the years. Howells noted that statx() will hopefully make it into glibc soon, so that developers can start using it. One attendee suggested that meant it was "ten years out" from actually being widely used, to some chuckles.

Steve French said that Samba has ways to add statx() functionality easily, but wondered what the best way to test if the kernel has the feature is. Dilger said that trying to use it, then setting a flag if it doesn't exist and not trying to use it again until a restart. But French thought that it didn't really make sense for Samba to build a special module for statx() if the kernel header files were missing the the proper pieces. Jeff Layton pointed out that Samba might be built on a kernel that has support, but run on one that doesn't, so checking is still required.

Dilger said that he would like to get statx() support into GNU ls, though the code is "eye-scratchingly bad". He does not know what the project's policies are with regard to changes like that, however. ls is a "poster child" for using all of the different functionality of statx(), he said.

The subject of testing for the system call came up. There are some tests, Dilger said. Ted Ts'o thought those tests should be ported to xfstests for more widespread testing. Howells suggested overriding stat() with statx() in xfstests, but it was not clear how serious he was about that. Eric Sandeen pointed out that Christoph Hellwig had talked about reverting statx() if no tests were forthcoming. Darrick Wong noted that his patches to support statx() in XFS needed review, since Hellwig has refused to do so awaiting more documentation and tests. But Howells said that both exist, though more tests are needed; the latter was generally agreed with by the attendees.

Talk then turned to adding a call for additional filesystem information, that Howells was calling statfsx(). Information like the granularity of timestamps and the maximum/minimum I/O size of the filesystem could be retrieved with such a call. Layton agreed that a call like that may be needed, "possibly with a better name". There is more that could be returned, such as server addresses, Howells said. Some of that kind of information might be filesystem-type-specific, Dilger said, but Layton thought it was best to have attributes that are not tied to the filesystem type.

The session ended with some ideas for things that could be added to statx() itself, including more Windows attribute bits (only two of the attributes are supported by the call currently), which would help Samba, Howells said. Trond Myklebust suggested that quota information might be another good addition, but Howells seemed skeptical that statx() was the right interface; "give us a patch and let's see". There are, evidently, some patches floating around to extend statx() further, which are likely to be dusted off and posted before long.