[filmor]

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.

[nix23]

>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.

[rleigh]

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.

[nix23]

>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.

Not sure if you would risk your customers data just because of that. I never had any problems with XFS.

>At some level, they must understand that both XFS and LVM are over 25 years old

Being a User of ZFS (on FreeBSD) myself, zfs is not much younger 2006.

>and RedHat in particular, don't have a competitive filesystem to offer.

That i really don't understand too. Maybe they think for "small" stuff HW-Raid or LVM is good enough and everything bigger is Ceph or Gluster anyway.

[rleigh]

Absolutely agreed, the customer's data is paramount, and I think from the perspective of supporting that with their well established in-house expertise, it makes sense.

However, XFS isn't perfect. As I wrote in a separate reply in this thread, my team in a previous position suffered catastrophic dataloss when a power cut took out some massive storage arrays. XFS does not handle power loss gracefully, and in two cases, the whole storage array was unrecoverable and required restoring from tape.

I use ZFS on FreeBSD (and Linux) too, and while it dates back to 2006 and was designed around ~2000, LVM and XFS date back at least a decade prior to that. They are a generation apart, and ZFS builds upon the knowledge of that previous generation, and its successes and its flaws.

Regarding competitive stuff, that's a mystery to me as well. My organisation went with some proprietary IBM storage array kit, but it was a real pain. Required hand compiling kernel modules against the RHEL kernel. And it still resulted in the above dataloss issues.