Probably never. ZFS isn't just a filesystem, it was developed to be an entire storage system that's vertically integrated, so ARC is a fundamental part of the filesystem design.
ZFS also has a huge legacy. Right now the license (probably) prevents you from legally shipping a compiled zfs module with the linux kernel, just solving that seems insurmountable. It's also supported on Illumos and FreeBSD, trying to refactor it to use the linux page cache would have a chance of introducing bugs to these platforms.
ZFS isn't really designed for local 'temporary' file systems (IMHO). You don't really need to nest checksums, create snapshots or volume manage when you're slugging pages between ram and nvme.
XFS is one of the only filesystems I've suffered serious catastrophic dataloss with. The other one is of course Btrfs which was and is the worst of the lot.
What was worrying was that the XFS dataloss was due an action totally out of our hands: a power outage at a substation which took out a whole area of the city. The whole datacentre lost power, and the XFS filesystems on some massive storage arrays were completely hosed. Just from power loss. It took days to put it all back from tape backups. XFS has long been known to have problems with unclean shutdowns, but total loss from a power outage is about as bad as it gets.
During my last >15 years of Linux usage, I had exactly the two filesystems you are advocating for here crashing on me:
- XFS, long time ago, had a bug that made it lose files silently
- BTRFS twice, most recently about a year ago in a super simple setup (no raid or any other fanciness). I wasn't able to recover it, after a while I at least got it to mount as ro and copied the contents away
These were all on Gentoo, so with relatively recent tools and vanilla kernels.
The only filesystems that I never had problems with were ext4 and reiserfs.
That was exactly the FS that eat my data back in ~2005. Never had problems with XFS or ZFS. With Btrfs well i just use it regularly since 2 years so i cant say much, but i think Redhat chose XFS for a reason.
The reason is they hired the XFS developers from SGI. And they bought Sistina for LVM. As a result, they have been wedded to both XFS and LVM for many years now, because there is likely a combination of wanting to maximise their investment into these technologies and developing the in-house expertise to support them very well, and also in having a number of staff who are deeply committed to them and don't want to change.
At some level, they must understand that both XFS and LVM are over 25 years old, and when compared with e.g. ZFS, are completely outclassed. Their current efforts developing Stratis, which is an attempt to provide more ZFS-like functionality by extending XFS, adding LVM thin pools, and managing it all with an unholy complex combination of daemons, D-BUS and Python looks like a logical progression based upon what they have to hand in house, but a strategic mistake when it can never approach ZFS in functionality or reliability simply because these technologies can only be extended so far because of fundamental design limitations. I'll be morbidly interested to see what they can stretch XFS to do. But I won't be using it myself.
What I find really surprising here is that Linux in general, and RedHat in particular, don't have a competitive filesystem to offer. There is absolutely nothing which matches ZFS.
ZFS also has a huge legacy. Right now the license (probably) prevents you from legally shipping a compiled zfs module with the linux kernel, just solving that seems insurmountable. It's also supported on Illumos and FreeBSD, trying to refactor it to use the linux page cache would have a chance of introducing bugs to these platforms.