<story><title>A way to do atomic writes</title><url>https://lwn.net/SubscriberLink/789600/101b40d06e0dfb80/</url></story><parent_chain></parent_chain><comment><author>ww520</author><text>Appending log based file system has a lot of appeals.  A lot of hard problems, like atomic write, become trivial.  A log based FS shares similar properties as the transaction log in RDBMS, making consistency and recovery easy.  Write performance is fantastic.  With enough cache memory, read performance should be good, too.  The only down-size is the performance hit when doing garbage collection.  More research in this area would be helpful.</text></comment>
<story><title>A way to do atomic writes</title><url>https://lwn.net/SubscriberLink/789600/101b40d06e0dfb80/</url></story><parent_chain></parent_chain><comment><author>jchrisa</author><text>One way modern distributed databases handle this is by assuming they can&amp;#x27;t trust the disks. When you are writing to multiple datacenters it makes recovery from disk errors just another kind of chaos resilience. The Calvin protocol takes this to its logical conclusion by moving the write-ahead-log to a Raft-like distributed consensus algorithm, where commits to the log span the cluster: &lt;a href=&quot;https:&amp;#x2F;&amp;#x2F;fauna.com&amp;#x2F;blog&amp;#x2F;consistency-without-clocks-faunadb-transaction-protocol&quot; rel=&quot;nofollow&quot;&gt;https:&amp;#x2F;&amp;#x2F;fauna.com&amp;#x2F;blog&amp;#x2F;consistency-without-clocks-faunadb-tr...&lt;/a&gt;&lt;p&gt;I will add that the different flavors of fsync, and what they do (and don&amp;#x27;t do), is always a source of entertainment in database engineering chat rooms.</text></comment>