My best guess is XFS coupled with Permabit (which they just bought and will open source) compression and dedupe services. Probably layered on an enhanced mdraid too.

I'm guessing that the ZFS licensing hairball is a bridge too far for even Red Hat, so they'll cobble together equivalent-ish functionality - even if it's not anywhere near as elegant as ZFS's integral data production and reduction.

XFS is the default FS on RHEL now, so likely that.

Do you know if XFS can shrink volumes yet? As far as I'm aware, that's the only limitation it has compared to other filesystems of that era.

It can't, but you're probably better off using trim/discard/virt-sparsify rather than shrinking filesystems. Even on filesystems like ext4 that support it, shrinking can cause strange fs performance problems.

Nope, still can't. Not online, not offline.

The following will sound snarky but I would personally prefer ext2 if the other choice is btrfs. "ButterFs because your data melts away"

XFS - the workhorse that keeps on running.

I am curious as to the same. The document says

> Red Hat will continue to invest in future technologies to address the use cases of our customers, specifically those related to snapshots, compression, NVRAM, and ease of use.

but it's unclear what this means exactly.

Like their Permabit acquisition: https://www.redhat.com/en/about/press-releases/red-hat-acqui...

Red Hat will never ship ZFS, because its an entity that exists in the US and a probable target for lawsuits / license violation if ZFS is included.

What's the risk involved for Red Hat in shipping ZFS? OpenZFS and ZFS-on-Linux are under the CDDL, a legitimate open-source license that some feel may be GPL-incompatible. Red Hat distributes non-GPL programs as a matter of routine, and I'm sure this includes other CDDL programs, especially considering Red Hat's enthusiastic involvement in the Java ecosystem.

The only potential risk is that the GPL is so virulently infectious that any driver is automatically GPL'd by virtue of its own existence as a compiled kernel module, but that possibility seems fairly remote, and it hasn't seemed to affect the distribution of other purportedly-non-GPL kernel modules.

I'm not a lawyer so maybe I'm missing something.

The risk is FUDdy, but not entirely imaginary. In particular there's the thread of a threat of patent lawsuits from a variety of players in the industry. Of course, that's always the case in this industry, so I don't buy it. But RH might, and that's their call.

My guess too is that if Canonical manages to go a few years without a lawsuit from kernel copyright holders then we might see more of what it is doing. But RH would -I guess!- still suffer from patent FUD and so stay away from ZFS.

That's all fine by me. The better for RH's competition. More competition, mo' betta.

I supposed their upgrade path is...

* Make fresh backups

* Verify the backups

* Re-install and use the backups

Basically. Those steps should be done regardless of FS. I heard this on a podcast recently but if you are not doing that you end up with "schrodinger backups"