EROFS, exFAT & EXT4 File-System Updates Arrive For Linux 5.19

[phoronix]

Phoronix: EROFS, exFAT & EXT4 File-System Updates Arrive For Linux 5.19

In addition to the buttery Btrfs feature updates for the in-development Linux 5.19 kernel, the exFAT, EXT4, and XFS file-system changes have all landed too so far in the first few days of the v5.19 merge window...

https://www.phoronix.com/scan.php?page=news_item&px=Linux-5.19-exFAT-EROFS-EXT4

[Solid State Brain]

In addition to the buttery Btrfs feature updates for the in-development Linux 5.19 kernel, the exFAT, EXT4, and XFS file-system changes have all landed too so far in the first few days of the v5.19 merge window.

What changed for XFS, in detail? I didn't see it linked or mentioned in the article.

[Namelesswonder]

Hope ext4 gets some more bugfixes in the meantime, I spent all of last week trying to diagnose corruption on a fresh install and it seems that fast commit and inline data have some bugs, or surface when combined with casefolding.

I started out with -O casefold,inline_data,fast_commit.

I do not know if fast commit played a part in the corruption, but on 5.18-rc7 I would get errors pertaining to fast commit. Although, fsck reported nothing and when booting 5.17 there were no errors generating. That was enough to not enable fast commit on the next install.

However, inline data was probably responsible for killing the install the next 4 times by inode corruption. inodes would be mangled within 36 hours of install and could not be recovered.

I did not test if the issues still occurred with just casefold, or just inline_data, as I was tired of doing installs for a week straight and just wanted a stable system.
So far it has been a week with just the default features and no problems.

[tytso]

In general, if you want a stable system and you don't have a burning need for the specific functionality or performance improvements which a new feature might provide --- you're probably better off sticking with the default features enabled by the latest file system utilities (or the utilities shipped with your distro, if you aren't willing to update to the latest upstream version). There is definitely a cost/benefits tradeoff to be considered, and that's true for all file systems.

For example,in the case of ext4, fast_commit decreases fsync latency; so unless you really need super-fast database performance (and more often than not, many workloads which use database are not bottlenecked by the database performance), or if you are running an NFS server (since every NFS protocol request implies an fsync), fast_commit is not going to buy you much. Inline_data is only helpful if you have a huge number of files which are under 144 bytes in size, if you stick with the default 256 byte inode. So if you are storing a huge number of old-style 140 character tweets, or are implementing a gigantic windows registry :-), inline_data isn't really going to help you very much.

Don't get me wrong. We're very grateful for people who use beta quality code and report problems; it's hard to get to production quality without that kind of super-valuable feedback. But sometimes I think that folks can be a bit too aggressive about trying the latest features Just Because. If you are doing regular backups, and you are willing to provide us with debugging information if things go wrong, we very much appreciate your contributions to the ext4 ecosystem.

[Namelesswonder]

In general, if you want a stable system and you don't have a burning need for the specific functionality or performance improvements which a new feature might provide --- you're probably better off sticking with the default features enabled by the latest file system utilities (or the utilities shipped with your distro, if you aren't willing to update to the latest upstream version). There is definitely a cost/benefits tradeoff to be considered, and that's true for all file systems.

For example,in the case of ext4, fast_commit decreases fsync latency; so unless you really need super-fast database performance (and more often than not, many workloads which use database are not bottlenecked by the database performance), or if you are running an NFS server (since every NFS protocol request implies an fsync), fast_commit is not going to buy you much. Inline_data is only helpful if you have a huge number of files which are under 144 bytes in size, if you stick with the default 256 byte inode. So if you are storing a huge number of old-style 140 character tweets, or are implementing a gigantic windows registry :-), inline_data isn't really going to help you very much.

Don't get me wrong. We're very grateful for people who use beta quality code and report problems; it's hard to get to production quality without that kind of super-valuable feedback. But sometimes I think that folks can be a bit too aggressive about trying the latest features Just Because. If you are doing regular backups, and you are willing to provide us with debugging information if things go wrong, we very much appreciate your contributions to the ext4 ecosystem.

Over the years I followed the features being added so I was itching to just test them out, even if the benefits would be minimal or not realized.
I had the foresight not to replace an existing install, the data loss was entirely just on a new drive that had the fresh install and nothing else.

I'll be putting aside the time to test and write a bug report since I am able to encounter the bug consistently so I will need to check if I can reproduce in a virtual machine.

Thank you for the heads up.