logoalt Hacker News

sausagefeet • today at 11:05 AM • 2 replies • view on HN

Is that entirely true? If you have a replication protocol like Viewstamped Replication you have the option to make a trade off for how many machines you the will fail concurrently vs forcing an fsync.

I think I'm a bit of an outlier here on that k never really understood why durability requires fsync. It doesn't help you if the storage dies. If durable storage is important to you, then isn't the only solution to synchronously replicate to a quorum of machines at which point an fsync isn't that relevant? What am I missing?


Replies

glimshe • today at 11:34 AM

You don't want other parts of the system thinking that the data is committed to durable storage when it isn't.

"Storage dies" is a broad set of causes. If there is power loss or a server crash due to a multitude of reasons, you want committed transactions to actually be committed.

Having replicas doesn't change the problem. If the orchestrator requires at least N replicas to be done committing the data, you'll have to wait for fsync in N of them.

Without fsync, the data anywhere could be sitting on a write back cache in memory instead of being flushed to the disk.

eatonphil • today at 12:11 PM

Synchronous replication to a quorum is a lot more expensive than an fsync.