Linux

Ext4 being "old" shouldn't put you off. It is demonstratively robust with a clear history of structure integrity. It has immense popularity and a good set of recovery tools and documentation. These are exactly what you are looking for in a filesystem.

I'm not saying EXT4 is the best for your requirements, just that age of a file system is like fine wine.

ext4 being old, and still being the main file system most distros use by default, should be enough alone to tell you being old isnt bad.

it means its battle tested, robust, stable, and safe. Otherwise it wouldnt be old and still be in widespread use.

btrfs is great for system stability because of snapshots. You can set it up to automatically make snapshots at a timed interval or every time you run pacman.

If something breaks, you can just revert to a previous snapshot. You can even do this from grub. It's a bit hard to set up, so if you want, you could use an arch based distro which automatically sets it up like GarudaOS.

ext4 works perfectly fine for me and most people.

If you're married stay away from ReiserFS.

Been using BTRFS for all disks and purposes for a few years, I would recommend it with the requirement that you research it first. There are things you should know, like how/when to disable CoW, how to manage snapshots, how to measure filesystem use, and what the risks/purposes of the various btrfs operations are. If you know enough to avoid doing something bad with it, it's very unlikely to break on you.

Ext4 is all I use, except for boot partitions that require different filesystems.

Be conservative and use the simplest thing that supports your needs and don't be suckered by feature lists. I have never needed more than ext4. It generally has the best all round performance and maturity is never a bad thing when it comes to filesystems. It isn't most suitable for some embedded and enterprise environments and if you are working with those you generally know the various tradeoffs.

I run ext4 inside lvm (inside luks)

Most people should use ext4. Only use something else if you want to tinker and don't need long term data storage.

Ext4 is old, but fast and very robust. You won't loose data or corrupt the filesystem if your system looses power. It can even survive partial wipes, if you accidentally overwrite the first few megs of you drive with a messed up dd, nearly all your data will be recoverable, including filenames and directory structure.

It doesn't have very fancy features, but it is the best tested and most robust option available. (also the fastest due to its simplicity)

Btrfs has things like copy on write files that can protect you from an accidental rm, but this won't save you from drive failures, so you still need backups for important data.

If you are planning to have any kind of database with regular random writes, stay away from btrfs. It's roughly 4-5x slower than zfs and will slowly fragment itself to death.

I'm migrating a server from btrfs to zfs right now for this very reason. I have multiple large MySQL and SQLite tables on it and they have accumulated >100k file fragments each and have become abysmally slow. There are lots of benchmarks out there that show that zfs does not have this issue and even when both filesystems are clean, database performance is significantly higher on zfs.

If you don't want a COW filesystem, then XFS on LVM raid for databases or ext4 on LVM for everything else is probably fine.

XFS is a possibility

Btrfs or xfs. Sometimes ext4.

ITT 5 answers by 4 people

We're moving towards more btrfs - or at least LVM+ where there's no btrfs support - on as much of our server fleet as we can, since the lack of snapshotting on the other filesystems is making consistent backups way too expensive resource- and time-wise.
With LVM it's at least possible to take a block-level snapshot - which is really inefficient compared to a file-level snapshot, but it at least provides a stable point for backups to run from, without having to pause all writes during the backup or risk running out a sliding window if allowing writes to continue.

For a home user (especially one who's not as well versed in Linux or don't have tinkering time), I'd personally suggest either ext4 - since it's been the default for a while and therefore often what's assumed in guides, or btrfs where distros include it as a default option - since they should be configured with snapshots out of the box in that case, which make it much harder for the system to break due to things like unexpected shutdowns while running updates.

I'd personally stay away from ZFS for any important data storage on home computers, since it's officially not supported, and basically guaranteed never to be either due to licensing. It can remain a reasonable option if you have the know-how - or at least the tinkering time to gain said know-how, but it's probably going to be suboptimal for desktop usage regardless.

Ext4 is probably going to be the fastest. When it comes to reliability, old is good. If you don't need any of the features Btrfs and ZFS, you'll reap higher performance using Ext4. Otherwise ZFS is more feature-complete compared to Btrfs, however it's generally not available as root fs option in OS installers. Ubuntu used to have it as an experimental option but I think that's gone now. If you know what you're doing you can use it as a root fs. Personally I'm using Ext4 on LVMRAID on a 2-way NVMe mirror. I might be switching to ZFS on root when I get to rebuild this machine. All my storage is using ZFS.

ext4 is good enough.

I usually just use EXT4, but perhaps you should check out F2FS. It's designed for solid state storage mediums, as while most were created with traditional spinning hard discs in mind

ext4 is perfectly fine for my needs. It's stable and just works.

I'm using btrfs for my desktop and laptop (and its snapshots have saved me a couple of times), and ZFS for my NAS and router. Both seem pretty robust.

I use ext4 for my desktop and zfs for my media server. Ext4 is faster, ZFS is more accurate and less corruptable.

It really depends on your priorities. Single drive is good for a home system with nothing really important on it.. once you get to wanting to keep it and where recovery from backups is too much downtime, you want at least a drive mirror.. nothing wrong with exr4+mdraid for that, although you don't get the checksumming that zfs gives it will be pretty fast & if a drive fails you can run degraded on one drive until you get the new drive in.

I've been running zfs for 10 years and not lost a single byte of data even after doing stupid shit like tripping over the sata cables and disconnecting half the drives. It's survived multiple drive failures (as long as the failures are on different bits of the disk, it recover get a clean copy onto a third drive, but it's a brown trousers moment when stuff like that happens).

Downsides, it aint fast, and it does tend to like lots of memory. You want it on your fileserver, not your gaming system.

IMO there's no point in a single drive zfs.. it'll warn you faster that the drive is f*cked but what do you do then?

I still swear by F2FS, been super reliable and very good perf

I like btrfs cause of transparent compression but I'm pretty sure other filesystems like ZFS have that too

O use ext4 at home and in servers that are not SLES HANA DB ones.

On SLES HANA servers I use ext4 for everything but the database partitions, for which SAP and SUSE support and recommend XFS.

In a few occasions people left the non-db partitions as the default on SUSE install, btrfs, with default settings. That turned out to cause unnecessary disk and processor usage.

I would be ashamed of justifying btrfs on a server for the possibility of undoing "broken things". Maybe in a distro hopping, system tinkering, unstable release home computer, but not in a server. You don't play around in a server to "break things" that often. Linux (differently from Windows) servers don't break themselves at the software level. For hardware breakages, there's RAID, backups, and HA reduntant systems, because if it's a hardware issue btrfs isn't going to save you - even if you get back that corrupted file, you won't keep running in that hardware, nor trust that "this" was the only and last file it corrupted.

EDIT: somewhat offtopic: I never use LVM. Call me paranoid and old fashioned, but I really prefer knowing where my data is, whole.