That's bad, Btrfs has really grown on me, especially the ability to mix drives of different sizes in a RAID configuration.

XFS is just not flexible enough, I don't like to be unable to shrink a partition once created.

It looks like I'll be back to ext4 and various kludges then.

Mind that btrfs will remain in RHEL7, but as soon as you go to RHEL8... you could just build your own kernel. Or use the centosplus kernel which will almost surely include it (as they've been including various RH-disabled modules for RHEL6 and 7 already).

> That's bad, Btrfs has really grown on me, especially the ability to mix drives of different sizes in a RAID configuration.

That's nice, but the fact RAID 1 still is implemented with critical defects might help understand RH position.

Or, assuming you get over your partition resizing fetish, just stick with XFS. It's as close to bulletproof as you'll find on Linux.

Yet to gain data checksums though.

I wonder if they'll be supporting ZFS on Linux now that it's gaining momentum?

I highly doubt Red Hat will ever touch ZFS. Oracle and Red Hat have a very tenuous relationship.

I hope Red Hat will support bcachefs though. I think it's the most promising alternative FS.

Unlikely, given the license of ZFS and its incompatibility with the GPL

didn't they settled to xfs long ago? Isn't the default root fs on fedora xfs?

Yes, btrfs was a tech-preview, meaning use if you want with no support or future guarantees. It has been officially dropped from future plans now.

And they're working on adding CoW and deduplication to XFS.

Wow I didn't know that. Very interesting to hear. Hopefully Docker support is considered as well.

overlayfs + XFS works very well, so it's probably not a priority (wild guess)

XFS went through a tech preview -> support -> default over the RHEL 5/6/7 lifecycles.

The fact btrfs has been yanked from tech preview would tend to suggest feedback has been so bad that they believe it can never make it to being supportable.

I wonder why that's the case? is it not well-maintained?

Running btrfs in production is still a nightmare in 2017.

At least the random kernel crashes stopped.

With proper care and feeding, it won't run out of metadata either but you need to monitor it closely and run nightly balances. Which probably kill your SSD.

Documentation sucks. Get used to monitor the btrfs IRC channel closely and deduce what to do and what not to do on which kernel version.

It works well for very particular use cases (file server with few random writes and much duplicate data). Cannot recommend it otherwise. Even Docker runs more stable on XFS.

Have a look at the RAID 1 implementation.

If you have a 2-disk mirror and one disk fails, you can mount the remaining disk one more time to try to recover.

If you try and mount it a second time it is marked permanently read-only and can never be recovered. You need to dump the data and rebuild from scratch.

It's 2017. It's been in development for almost a decade, and getting the simplest RAID case correct hasn't worked.

RAID 5 and 6 were found to be losing data without a drive going bad. I pulled all my data off to backup and restored it on a freshly built array under XFS. That's not something I enjoy doing too often.

Yeah, having scrubs corrupt good data is basically the worst-case scenario for an FS whose selling point is checksumming for data integrity.

I ran btrfs for several years, and while the features are great (per-subvolume RAID policies, lightweight snapshots, unRAID-style RAID), I got sick of testing my backups regularly. I wouldn't be surprised if that's not uncommon.