I’ve defaulted to XFS since it became available for Linux, and never had any problems. Only once, some time around 2009, did I try ext3 and it forgot to flush a lot of data that were lost. I don’t see why anyone would use ext over XFS.
XFS is adding pretty radical features and reworking its internals in interesting ways, it's Ext4 the one that doesn't really see that many changes these days.
When XFS was designed, the storage ecosystem was spinning rust attached using PATA and SCSI. We've developed quite a bit since then, with things like SAS, NVMe, and SSDs. Storage have gotten over an order of magnitude more throughput, over an order of magnitude less latency, and several orders of magnitude more IOPS.
Running a filesystem designed for ancient hardware means you won't be taking advantage of several decades of innovation.
In what ways would you say that ext4 takes advantage of the latest several decades of innovation, where XFS does not? Both XFS and ext2 were first released around 1993, and it is safe to say that XFS was more advanced than ext2 at that time, given that it had journaling and ext2 did not.
If I wanted something actually novel, I would go for ZFS or one of its clones.
> Is this triggered under certain workloads, or has it been chewing data for everyone, and how much?
Unless you are checksumming your files through a daemon run on a schedule (IDS style) AND manually review the results every now and then, you can't know.
I have versioned backups for a few months. Most people don't and can't (it requires a lot of storage)
Even if they have them, the diffing needs to be done.
Given the past problems with ZFS, I think I'll write a summarizer, that creates a database of metadata for each backup: it will be small to keep around, and may be use more easily to determine which backup contains the uncorrupted file.
I use borgbackup so the storage requirements are fairly low if the data does not change too much (which is my case). Also diffs are just a « borg diff » away.
>The commit got merged in 6.5-rc1 so all stable kernels that have
91562895f803 ("ext4: properly sync file size update after O_SYNC direct
IO") before 6.5 are corrupting data - I've noticed at least 6.1 is still
carrying the problematic commit. Greg, please take out the commit from all
stable kernels before 6.5 as soon as possible, we'll figure out proper
backport once user data are not being corrupted anymore. Thanks!
I'm very conservative in the versions or critical components like kernels or dkms modules, that didn't protect me against the ZFS bug, but it seems to have avoided me this EXT4 bug!
