3 ms·

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, inconsistent

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 4y ago
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.
- bravetraveler 4y ago
  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.
- tokenrove 4y ago
  This paper was influential with regards this idea: https://www.usenix.org/conference/hotos-ix/crash-only-software https://www.usenix.org/conference/hotos-ix/crash-only-softwa... I don't think it's that unusual, but obviously there are tradeoffs.

empthought 4y ago

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.

bravetraveler 4y ago
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.
tokenrove 4y ago
This paper was influential with regards this idea: https://www.usenix.org/conference/hotos-ix/crash-only-software https://www.usenix.org/conference/hotos-ix/crash-only-softwa... I don't think it's that unusual, but obviously there are tradeoffs.