Kernel 6.2 promises various file system improvements

The upcoming Linux kernel 6.2 should see improved file system handling, including performance gains for SD cards and USB keys, as well as FUSE. As for next-generation storage subsystems…not so much.

For a mature OS kernel, there are still significant improvements being made in Linux’s handling of current disk formats, and this should improve when kernel 6.2 comes out sometime in early 2023.

A patch from Sony engineer Yuezhang Mo speeds up the creation of new files or directories on an exFAT disk with a lot of files – the more files, the greater the optimization. This follows the same programmer’s previous patch to improve exFAT handling, back in March.

After Microsoft published the exFAT specification in 2019 and entered the Linux kernel in 2020, its support has steadily improved. Linux recently gained the ability to repair exFAT volumes, thanks to a patch from developer Samsung Namjae Jeon, which keeps the exFAT drive out of the tree for older kernels — such as those used in Android. Its commit history shows a lot 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 also works. Posted in a detailed patch to add a custom VFS API for POSIX ACLs. It’s been supported for a long time, as you can see from this description of how it works from 2002, but the new version should clean up and simplify its handling. Brauner has also introduced a patch to support ID mapping mounts for SquashFS volumes. This is a complement to his previous patch which introduced ID mapping swatches, which also contains an explanation of how they work and what they are for.

There are improvements to some of the more established file systems, too. The first is a list of fixes and improvements for XFS, aimed at the important new feature of online repair. Another patch provides performance improvements for volumes installed with FUSE – in other words, where the file system code runs in the userspace program, not as part of the kernel. There are even some bug fixes for ext4 which is now worthy of respect.

There are also some improvements in Btrfs, particularly in its handling of RAID 5 and 6. In particular, one patch addresses the “read-modify-write destruction” issue for Btrfs RAID5 (but not RAID6) arrays. This is good stuff, but these disk layouts are still not recommended. In special product documentation words:

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

Since this is the FOSS file system of the FOSS operating system, of course there are workarounds for this, such as using the built-in Linux kernel mdraid cross support mdadm command, to create a RAID-6 volume, then format it with Btrfs. Our story about upgrading the oldest Debian installation mentioned that it was running 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 old Linux nerd.

Simplifying and consolidating this kind of complex disk configuration is exactly what next-generation file systems were meant to deliver, but while code changes continue to emerge, two of the most significant have gone relatively quiet.

While Ubuntu continues to maintain its ZSys code, there isn’t much activity. It’s worth noting that there hasn’t been a new post on ZSys’ blog since the Ubuntu 20.04 timeframe, and some users are starting to wonder what’s going on, as well as whether it should be removed.

This is certainly not due to a lack of development at OpenZFS, which released version 2.1.7 earlier this month, with plenty of updates and support for up to Linux 6.0. There are also active and innovative third-party tools that use it, such as ZFSBootMenu. It is 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 bullet releases since then. However, the changelog doesn’t show any very significant work. It still targets a Fedora version before the current one, for example. You can use it in RHEL 9, but it remains an unsupported tech preview, as happened in RHEL 8 in 2019.

We could be wrong, but it seems to us as if both Canonical and Red Hat have lost interest in moving this innovative technology forward. We’d like to see someone else select, merge, and optimize projects, as some Android vendors do with exFAT. It appears to be a huge opportunity for companies creating their own Ubuntu-based distributions, such as Linux Mint and ZorinOS, that address perceived weaknesses in their flagship desktop product. ®

#Kernel #promises #file #system #improvements

Leave a Reply

Your email address will not be published. Required fields are marked *