Linux kernel 6.2 promises multiple filesystem improvements

Meanwhile the next-gen Linux filesystems are going nowhere fast

The forthcoming Linux kernel 6.2 should see improved filesystem handling, including performance gains for SD cards and USB keys, as well as FUSE. As for the next-gen storage subsystems… not so much.

For a mature OS kernel, there are still considerable improvements being made in Linux's handling of existing disk formats, and this should improve when kernel 6.2 appears at some point in early 2023.

A patch from Sony engineer Yuezhang Mo makes it quicker to create new files or directories on an exFAT disk with lots of files on it – and the more files there are, the bigger the improvement. This follows the same programmer's earlier patch to improve exFAT handling, in March.

Following Microsoft publishing the exFAT spec in 2019 and it going into the Linux kernel in 2020, its support has steadily improved. Just recently Linux gained the ability to repair exFAT volumes, thanks to a patch from Samsung developer Namjae Jeon, who maintains the out-of-tree exFAT drive for old kernels – such as the one used in Android. Its commit history shows lots of contributions from the Sony programmer. Another Samsung engineer, Jaeguk Kim, contributed a patch to improve F2FS, the Flash Friendly File System.

Former Ubuntu and now Microsoft engineer Christian Brauner has been busy, too. He sent in a detailed patch to add a dedicated VFS API for POSIX ACLs. These have been supported for a long time, as you can see from this description of how they work from 2002, but the new release should clean up and simplify their handling. Brauner also submitted a patch to support ID-mapped mounts for SquashFS volumes. This is supplementary to his earlier patch which introduced ID-mapped mounts, which also contains an explanation of how they work and what they're for.

There are improvements to some of the more established filesystems, too. One is a list of fixes and improvements for XFS, which is aiming towards the important new feature of online repair. Another patch brings performance improvements to volumes mounted with FUSE – in other words, where the filesystem code is running in a userspace program, not as part of the kernel. There are even some bugfixes for the now-venerable ext4.

There are also some improvements in Btrfs, especially in its handling of RAID 5 and 6. In particular, one patch addresses the "destructive Read-Modify-Write" problem for Btrfs RAID5 (but not RAID6) arrays. This is good stuff, but these disk layouts are still not recommended. In the words of the product's own documentation:

the feature should not be used in production, only for evaluation or testing.

Being that this is a FOSS filesystem for a FOSS OS, there are, of course, workarounds for this, such as using the Linux kernel's built-in mdraid support via the mdadm command, to create a RAID-6 volume, then format that with Btrfs. Our story on upgrading possibly the oldest Debian install mentioned that it ran LVM, on RAID, on LVM. This kind of thing is possible and people do it, but that doesn't mean it's a good idea if you're not an ascended elder of Linux.

Simplifying and integrating this sort of complex disk config is exactly what next-generation filesystems were supposed to deliver, but while code changes continue to trickle in, two of the most significant have gone relatively quiet.

While Ubuntu continues to maintain its ZSys code, there isn't much activity. It's notable that there hasn't been a new post on the ZSys blog since the Ubuntu 20.04 time frame, and some users are starting to ask what's happening, as well as whether it should be removed.

This certainly isn't due to lack of development in OpenZFS, which released version 2.1.7 earlier this month, with lots of updates and support for up to Linux 6.0. There are also active and innovative external tools using it, such as ZFSBootMenu. It's also supported in NixOS, the innovative distro we talked about last week.

On the Red Hat side of things, the Stratis team released version 3.4 in November, and three minor point-releases since then. However, the change log doesn't show any very significant work. It still targets the version of Fedora before the current one, for instance. You can use it in RHEL 9, but it remains an unsupported tech preview, as it did in RHEL 8 in 2019.

We could be wrong, but it looks to us as if both Canonical and Red Hat have lost interest in pushing this innovative tech forward. We would love to see someone else pick the projects up, integrate and improve them, as some Android vendors are doing with exFAT. It seems like a big opportunity for companies which make their own Ubuntu-based distros, such as Linux Mint and ZorinOS, which address perceived weaknesses in the mainline desktop product. ®