<story><title>Files Are Fraught with Peril (2019)</title><url>https://danluu.com/deconstruct-files/</url></story><parent_chain><item><author>josephg</author><text>This situation is so terrible, and its embarrassing that despite decades of work, our industry doesn&amp;#x27;t seem to be able to solve this problem in any modern operating system. (Edit: Apparently except for windows vista!)&lt;p&gt;It seems obvious to me that we need a transactional filesystem API with methods like:&lt;p&gt;&lt;pre&gt;&lt;code&gt;  fbegin()
  fwrite() &amp;#x2F; rename &amp;#x2F; etc
  fcommit()
&lt;/code&gt;&lt;/pre&gt;
Most of the write calls wouldn&amp;#x27;t return errors directly. Then the fcommit() call would atomically flush the locally buffered changes to the filesystem. If an error happened, the API should guarantee that the final state either contains all changes or none of them. The commit call should either block the thread until changes are safely stored on disk, or use a completion callback. This API probably couldn&amp;#x27;t span multiple filesystems, but thats fine in practice. And bonus points if the API supports snapshot reads within the transaction.&lt;p&gt;This would dramatically simplify the code in every program that wants to safely interact with the filesystem. And it would remove the perennial, justified anxiety database engineers carry that they&amp;#x27;re doing something subtly wrong without even knowing. Because fsync() is so coarse, I suspect performance would &lt;i&gt;improve&lt;/i&gt; with this API, too. (So long as the transactions are mostly small.)&lt;p&gt;But why don&amp;#x27;t we have this API already? My theory is that kernel developers don&amp;#x27;t write enough userspace software to understand how bad the status quo is. And most people writing software in userland don&amp;#x27;t understand the kernel well enough to feel empowered to change it. Adding an API like this might also need changes in the filesystems.&lt;p&gt;But wow, it would be a huge boon to humanity to have a filesystem API which isn&amp;#x27;t so braindead. How many more decades do we need to have our files corrupt by default when errors happen? I wince every time I&amp;#x27;m playing a video game and it has that &amp;quot;saving - don&amp;#x27;t turn off your console!&amp;quot; animation. Or during OS updates. Data corruption happens because we implemented the wrong abstractions 50 years ago and somehow forgot that code is mutable.</text></item></parent_chain><comment><author>the8472</author><text>&amp;gt; Because fsync() is so coarse&lt;p&gt;You can do some work in advance with sync_file_range. fsync is still needed to write out the metadata, but it&amp;#x27;ll have to do less work and you may be able to get better pacing and backpressure that way.&lt;p&gt;&amp;gt; Then the fcommit() call would atomically flush the locally buffered changes to the filesystem. If an error happened, the API should guarantee that the final state either contains all changes or none of them.&lt;p&gt;Many existing filesystems simply cannot support such an API because they&amp;#x27;re not journaling or CoW.
Another issue might be that multiple transactions could overlap and be of unbounded size, so now you would need MVCC, exclusive locking or the ability for the kernel to provide feedback to userspace that it will immediately rollback the transaction due to resource limits or conflicts. This suddenly looks more and more like a database than a posix filesystem.&lt;p&gt;There are many use-cases that don&amp;#x27;t need such hard guarantees and want throughput, minimal overhead and latency instead. Lazy writes that the kernel can flush to disk whenever it feels like provide a lot of the performance that we take for granted when working with large amounts of data.&lt;p&gt;&amp;gt; And it would remove the perennial, justified anxiety database engineers carry that they&amp;#x27;re doing something subtly wrong without even knowing.&lt;p&gt;I think the postgres&amp;#x2F;fsync error saga raised awareness of that and there were some proposals how to provide a better error channel to userspace.</text></comment>
<story><title>Files Are Fraught with Peril (2019)</title><url>https://danluu.com/deconstruct-files/</url></story><parent_chain><item><author>josephg</author><text>This situation is so terrible, and its embarrassing that despite decades of work, our industry doesn&amp;#x27;t seem to be able to solve this problem in any modern operating system. (Edit: Apparently except for windows vista!)&lt;p&gt;It seems obvious to me that we need a transactional filesystem API with methods like:&lt;p&gt;&lt;pre&gt;&lt;code&gt;  fbegin()
  fwrite() &amp;#x2F; rename &amp;#x2F; etc
  fcommit()
&lt;/code&gt;&lt;/pre&gt;
Most of the write calls wouldn&amp;#x27;t return errors directly. Then the fcommit() call would atomically flush the locally buffered changes to the filesystem. If an error happened, the API should guarantee that the final state either contains all changes or none of them. The commit call should either block the thread until changes are safely stored on disk, or use a completion callback. This API probably couldn&amp;#x27;t span multiple filesystems, but thats fine in practice. And bonus points if the API supports snapshot reads within the transaction.&lt;p&gt;This would dramatically simplify the code in every program that wants to safely interact with the filesystem. And it would remove the perennial, justified anxiety database engineers carry that they&amp;#x27;re doing something subtly wrong without even knowing. Because fsync() is so coarse, I suspect performance would &lt;i&gt;improve&lt;/i&gt; with this API, too. (So long as the transactions are mostly small.)&lt;p&gt;But why don&amp;#x27;t we have this API already? My theory is that kernel developers don&amp;#x27;t write enough userspace software to understand how bad the status quo is. And most people writing software in userland don&amp;#x27;t understand the kernel well enough to feel empowered to change it. Adding an API like this might also need changes in the filesystems.&lt;p&gt;But wow, it would be a huge boon to humanity to have a filesystem API which isn&amp;#x27;t so braindead. How many more decades do we need to have our files corrupt by default when errors happen? I wince every time I&amp;#x27;m playing a video game and it has that &amp;quot;saving - don&amp;#x27;t turn off your console!&amp;quot; animation. Or during OS updates. Data corruption happens because we implemented the wrong abstractions 50 years ago and somehow forgot that code is mutable.</text></item></parent_chain><comment><author>martinhath</author><text>This [0] mail from Linus might shed some light over this.&lt;p&gt;[0]: &lt;a href=&quot;https:&amp;#x2F;&amp;#x2F;lkml.org&amp;#x2F;lkml&amp;#x2F;2009&amp;#x2F;3&amp;#x2F;25&amp;#x2F;632&quot; rel=&quot;nofollow&quot;&gt;https:&amp;#x2F;&amp;#x2F;lkml.org&amp;#x2F;lkml&amp;#x2F;2009&amp;#x2F;3&amp;#x2F;25&amp;#x2F;632&lt;/a&gt;</text></comment>