[bravetraveler]

While I agree it's a bit of a weird take, for example -- there may be performance tradeoffs made in any given workload to make the disk consistent, inconsistently

The 'most' there is doing some effort

It is actually quite a common practice for those being audited for disaster recovery to do exactly that -- yank cables. More realistically, flip some switches

We do it once a year, set aside a region and time... then test our processes

It serves a few purposes, most importantly -- are our services fault tolerant, and can we bring them back?

I think it's reasonable to trap the signals and make a best effort basis, knowing that PID 1 (or the environment) will eventually have to SIGKILL you -- ready or not

Just because we can't save all of the state doesn't mean we shouldn't try

[empthought]

Right, there are failure modes that have to be tested and accounted for, and one of them is the state being inconsistent after a shutdown.

The previous poster seemed to advocate for not thinking of this as a failure mode at all but rather normal operation, which I just don’t see as true.

[tokenrove]

This paper was influential with regards this idea: https://www.usenix.org/conference/hotos-ix/crash-only-softwa...

I don't think it's that unusual, but obviously there are tradeoffs.

[bravetraveler]

Totally, it's certifiably untrue!

Take the InnoDB storage engine in MySQL/MariaDB for example.

For performance (and likely other) reasons, this file only grows. It never shrinks... it will only go to 0 or grow.

The DB (or individual tables, depending on config) have to be truncated/emptied to reclaim those blocks.

Stop it uncleanly and there's a good chance you'll have to sacrifice a considerable amount of the data just to get the engine to start

This and countless other things have to make consistency trade-offs. While everything could be written to only operate atomically, it will also slow to a crawl.