What's with all these hip filesystems and how are they different?

As with every software/product: they have different features.

ZFS is not really hip. It's pretty old. But also pretty solid. Unfortunately it's licensed in a way that is maybe incompatible with the GPL, so no one wants to take the risk of trying to get it into Linux. So in the Linux world it is always a third-party-addon. In the BSD or Solaris world though ....

btrfs has similar goals as ZFS (more to that soon) but has been developed right inside the kernel all along, so it typically works out of the box. It has a bit of a complicated history with it's stability/reliability from which it still suffers (the history, not the stability). Many/most people run it with zero problems, some will still cite problems they had in the past, some apparently also still have problems.

bcachefs is also looming around the corner and might tackle problems differently, bringing us all the nice features with less bugs (optimism, yay). But it's an even younger FS than btrfs, so only time will tell.

ext4 is an iteration on ext3 on ext2. So it's pretty fucking stable and heavily battle tested.

Now why even care? ZFS, btrfs and bcachefs are filesystems following the COW philisophy (copy on write), meaning you might lose a bit performance but win on reliability. It also allows easily enabling snapshots, which all three bring you out of the box. So you can basically say "mark the current state of the filesystem with tag/label/whatever 'x'" and every subsequent changes (since they are copies) will not touch the old snapshots, allowing you to easily roll back a whole partition. (Of course that takes up space, but only incrementally.)

They also bring native support for different RAID levels making additional layers like mdadm unnecessary. In case of ZFS and bcachefs, you also have native encryption, making LUKS obsolete.

For typical desktop use: ext4 is totally fine. Snapshots are extremely convenient if something breaks and you can basically revert the changes back in a single command. They don't replace a backup strategy, so in the end you should have some data security measures in place anyway.

*Edit: forgot a word.

ZFS is a crazy beast that's best for high end server systems with tiered storage and lots of RAM.

ext4 is really just a basic file system. Its superior to NTFS and fat as it does have extra features to try to prevent corruption but it doesn't have a large feature set.

Btrfs is kind of the new kid on the block. It has strong protection against corruption and has better real world performance than ext4. It also has more advanced features like sub volumes and snapshots. subvolumes are basically virtual drives.

Another few older options include things like XFS but I won't go into those.

List of filesystems: https://en.m.wikipedia.org/wiki/Comparison_of_file_systems

The principled "old" way of adding fancy features to your filesystem was through block-level technologies, like LVM and LUKS. Both of those are filesystem-agnostic, meaning you can use them with any filesystem. They just act as block devices, and you can put any filesystem on top of them.

You want to be able to dynamically grow and shrink partitions without moving them around? LVM has you covered! You want to do RAID? mdadm has you covered! You want to do encryption? LUKS has you covered? You want snapshotting? Uh, well...technically LVM can do that...it's kind of awkward to manage, though.

Anyway, the point is, all of them can be mixed and matched in any configuration you want. You want a RAID6 where one device is encrypted split up into an ext4 and two XFS partitions where one of the XFS partitions is in RAID10 with another drive for some stupid reason? Do it up, man. Nothing stopping you.

For some reason (I'm actually not sure of the reason), this stagnated. Red Hat's Strata project has tried to continue pushing in this direction, kind of, but in general, I guess developers just didn't find this kind of work that sexy. I mentioned LVM can do snapshotting "kind of awkward"ly. Nobody's done it in as sexy and easy way to do as the cool new COWs.

So, ZFS was an absolute bombshell when it landed in the mid 2000s. It did everything LVM did, but way way way better. It did everything mdadm did, but way way way better. It did everything XFS did, but way way way better. Okay it didn't do LUKS stuff (yet), but that was promised to be coming. It was Copy-On-Write and B-tree-everywhere. It did everything that (almost) every other block-level and filesystem previously made had ever done, but better. It was just...the best. And it shit all over that block-layer stuff.

But...well...it needed a lot of RAM, and it was licensed in a way such that Linux couldn't get it right away, and when it did get ZFS support, it wasn't like native in-the-kernel kind of stuff that people were used to.

But it was so good that it inspired other people to copy it. They looked at ZFS and said "hey why don't we throw away all this block-level layered stuff? Why don't we just do every possible thing in one filesystem?".

And so BtrFS was born. (I don't know why it's pronounced "butter" either).

And now we have bcachefs, too.

What's the difference between them all? Honestly mostly licensing, developer energy, and maturity. ZFS has been around for ages and is the most mature. bcachefs is brand spanking new. BtrFS is in the middle. Technically speaking, all of them either do each other's features or have each other's features on their TODO list. LUKS in particular is still very commonly used because encryption is still missing in most (all?) of them, but will be done eventually.

I've started using BTRFS on my laptop with OpenSUSE and on my Steam Deck. It does two things for me, which I'm interested in. On OpenSUSE it does a snapshot before every system update. So if anything goes wrong I can easily roll back.

On the Steam Deck I love the deduplication. It's really great for a ton of Windows games that all need their own little "Windows" environment which amounts to a GB or two per game. With BTRFS I only use that space once.

Using Btrfs you can do some pretty cool snapshotting: It's basically like system restore of Windows but MUCH faster and pretty seamless. Even if you annihilate the whole operating system you can restore the snapshot and voila, have fun! It also has compression which can save some wear on SSDs and of course give you some more free(tm) storage space, which is cool [actual benefits depend on workload*]

btrfs = B-tree filesystem

B-trees are a data structure.

I know I'm not making a helpful contribution here, but I've been wondering about this stuff for a while myself and this thread has some great answers. Thanks for asking this OP.

ButterFS (btrfs...its actually "better" right?),

I'm still waiting to find out who the BCA Chefs are.

related question, although i don't think it's big enough for a post of its own.

if i use btrfs subvolumes, does it mean that i can have one EFI partition and one root partition, and then subdivide the root partition using subvolumes? how would that work during the installation process? or is it done after installation?

I don’t know about the new ones, but ReiserFS was a killer back in the day.

ext4 certainly has its place, it's a fine default file system, there's really no problems with it.

But others, like ZFS and BTRFS, have features that you may want to use, but ext4 doesn't do: fs snapshots, data compression, built in encryption (to a degree, usually only happening for data and some of the metadata, so LUKS is often better IMHO), checking for bitrot and restoring it when possible (whether it is depends on your config), quotas per user group or project, spanning multiple disks like with RAID but safer (to a degree), and others.

I use f2fs on my Raspberry Pis, it's designed for flash storage and appears to have much better performance than ext4 on the same device. I'm not sure whether it's suitable for SSDs, or just SD cards and USB (these devices are optimised for FAT and f2fs utilises that optimisation). When I tried to use f2fs on a proper laptop it was too early and the distro didn't support booting from it. I assume that has changed now.

As for the others, I usually stick with ext4 as I've never seen a compelling reason not to.

Not sure about the other ones, but I use Btrfs because of subvolumes and backups.

Subvolumes are like special folders inside of your partition that mount separately. Ex. In my btrfs partition, I have a @home partition that is mounted to /home

This makes it easier to choose what you are backing up, because you can say, "just copy everything in @home to the backup location"

If I got any of that wrong, feel free to correct me!

After using ext4 for yyyeeeaaaarrrrrsss, when I upgraded my MX21 to MX23 I used btrfs, with subvolumes, especially for easy backup/snapshot/timeshift.

Just at install, super easy, create a small ext4 boot partition on the SSD, then a big LUKS partition, format with btrfs, create subvolumes for / /home /var /swap and that's it. No hassle with sizing correctly.

btrfs seems pretty stable. I see no diff in performance compared to ext4 because my application are not that dependant to FS speed, and with SSD anyway?

oh yeah, built-in compression too!

you're forgetting about the all new bcachefs

dunno I also wonder if it's worth it for personal use

I just use ext4.

Fedora uses BTRFS so I get the features are the best argument for it

https://www.phoronix.com/news/Linux-5.14-File-Systems

But it seems F2FS is by far the fastest in many areas! Its used in Android, optimized for Flash storage.

Did BTRFS fix the Raid-5 problem or no?