Most Linux machines stand on it

Talking about a filesystem is like talking about air. It is the layer everything else rests on, and precisely because it works, nobody mentions it. ext4 has been the default on the overwhelming majority of Linux installations for years, from home desktops to cloud servers, and that dominance is not an accident of inertia. Two decades of refinement produced something close to textbook behaviour: a journal that records intent before it records change, so an unexpected power cut leaves a structure that can be reasoned about rather than a pile of half written blocks.

The properties that matter in practice are unglamorous. Large files and large partitions are handled without drama. Extended attributes and access control lists are there when a backup tool needs them. Delayed allocation batches writes in a way that keeps fragmentation low on a busy disk. And the installed base is so vast that almost every failure mode has been encountered, reported and fixed long before you meet it. Choosing it is not exciting, and it is almost never wrong.

A toolchain rather than a single program

A filesystem is only as good as the tools that can inspect and repair it, and this is where the e2fsprogs collection earns its place. Creating a filesystem is one command with flags that mean what they say. Checking consistency after an unclean shutdown is another, and it is the program that turns a machine that will not boot into a machine that will. Lower level tools can walk the internal structures directly, which is what forensic work needs when the ordinary view is lying.

The everyday value shows up in the classic situations: a partition that refuses to mount, a disk that reports errors after a cable was kicked, a server that came back from a power event with a filesystem marked dirty. In almost every case the resolution is a check and a repair, and the reason it is boring is that the tools have been doing it reliably for a very long time.

The greatness of ext4 is its silence: twenty years of catching every write without complaint, which turned the filesystem from a problem into an assumption.

The rules that should not be skipped

Unmount before checking. A consistency check on a mounted filesystem is not a brave shortcut, it is a way to create the corruption you were looking for. Boot from a rescue medium or work from another machine when the filesystem in question is the one holding the running system, and let the check finish even when it seems slow, because interrupting it is how a repairable problem becomes an unrepairable one.

Two more habits are worth the thirty seconds they cost. Keep a note of the flags a filesystem was created with, since they decide what can be changed later without a rebuild. And do not chase exotic mount options on a machine that holds data you care about; the defaults have been tuned by more people than your particular theory has. Novelty belongs on a test machine.

When something else is the right answer

ext4 is a general purpose filesystem and does not pretend otherwise. If the requirement is snapshots and checksums with volume management built in, a copy on write design is the better fit. If the requirement is a shared store across operating systems, something with native support on both sides avoids a translation layer. If it is a USB stick that will be pulled out without warning, a simpler design with a different trade off may survive better.

Knowing the boundary is part of using the default well. Choose ext4 when nothing in the requirement list argues against it, which describes the majority of machines, and then stop thinking about it. A filesystem that never enters your thoughts is a filesystem that is doing its job.