[pengaru]

> Before that, fsck after a crash seemed a little too exciting.

It was more the opposite IME (90s-era linux): fsck after a crash was boring and time-consuming, and we grew increasingly impatient as capacities grew.

Prior to having a journaling filesystem and log replay @ reboot/mount, the filesystem was often plain conservatively implemented using methods like two-phase-commits and arguably kept more consistent due to the repeated exhaustive checking process at every dirty mount.

We went through a phase of putting a lot of trust into the hardware keeping things consistent/no-bitrot and more or less assuming everything was fine after a journal replay. Only relatively recently did we start getting checksums of metadata to detect such failures, that's still not a universal feature.

The lack of frequent fscks creates opportunity for hidden corruption from either bugs or hardware errors to go unnoticed until it's far too late to recover from... There's a reason filesystems tend to have a max mount count before a fsck is forced, even if not dirty.

[mjevans]

Checksums for integrity at all.

Scrubs / checks / etc for online consistency check.