[bityard]

You are going to have a bad time when your / filesystem fills up, regardless of the filesystem type. This is one of the reasons for separate /usr, /var, /home, etc that many seem to have forgotten. Smaller blast radius when there is a problem.

The reserved space in ext4 doesn't do you any good if root is the user that filled up the disk in the first place, which is far and away the most common thing I see.

[trumpdong]

On ext4 things will start failing with -ENOSPC but recovery is as simple as deleting files that are taking up space - which may or may not require a reboot into single-user mode depending on how badly the running system is borked - but the filesystem remains intact, you don't have to drop the journal, you don't have to run fsck or any other repair tool. You can just delete files and get the space back.

[ericbarrett]

This is true of XFS too; I have run it in production on both RedHat and Debian/Ubuntu based distros for decades and have never had issues after an FS full event. I usually reboot a server that has had the root FS full because sometimes service logging will not recover from write failures, but I've never had to xfs_repair.

[wongarsu]

On servers I've usually had a bad time when / fills up. But using Linux as a desktop with ext4 I regularly fill the file system up (laptop with a too small SSD, so this happens quickly when batch downloading) and nothing bad happened so far. Which is approximately the same experience I have on Windows