News for hackers. Stuff that matters.

A comment on When etcd crashes, check your disks first. Parent comment

Re:When etcd crashes, check your disks first by weiliddat on Saturday February 21, 2026 @06:41AM (#47099859)
Yes, but they wrote it’s for a demo and it’s fine if they lost the last few seconds in the event of unexpected system shutdown.

And also in prod, etcd recommends you run with SSDs to minimize variance of fsync/write latencies

[ Parent | on HN ]
Re:When etcd crashes, check your disks first by ahoka on Saturday February 21, 2026 @07:31AM (#47100186)
Getting into an inconsistent state does not just mean “losing a few seconds”.
[ Parent | on HN ]
Re:When etcd crashes, check your disks first by weiliddat on Saturday February 21, 2026 @11:00PM (#47108016)
How would you get into an inconsistent state based on an fsync change?

Edit: I meant what sequence of events would cause etcd to go into an inconsistent state when fsync is working this way

[ Parent | on HN ]
Re:When etcd crashes, check your disks first by _ananos_ on Sunday February 22, 2026 @03:07AM (#47109255)
data corruption, since fsync on the host is essentially a noop. The VM fs thinks data is persistent on disk, but it’s not - the pod running on the VM thinks the same …
[ Parent | on HN ]