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.
Comments
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.
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.
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.