PostgreSQL's fsync surprise
I&#x27;ve said it before and I&#x27;ll say it again: Modern filesystems straight out expose the wrong API for 99% of applications. App developers almost never think of data as a stream of bytes. We think of data as a set of records. Values in the set change through atomic modification events.<p>The fundamental API primitives should be atomic changes. Atomic write (bytes), and atomic append. The funny thing about it is that POSIX already supports basically this API (datagrams) for both IPC and networking. It just doesn&#x27;t support this API in the one place it would be most useful - the filesystem.<p>Ideally I want:<p>- Write() to be blocking &#x2F; atomic by default. Don&#x27;t return until data is safely committed.<p>- A transactional API: begin(fd); write(); write(); err = commit(fd). If any error happens, commit returns the error and <i>none</i> of the data is stored.<p>- An IOCP-style API for non-blocking applications. This is the API databases want to use, with the loop being &lt;get network request&gt;, &lt;write data to filesystem&gt;, &lt;yield&gt;, &lt;get write completion event&gt;, &lt;send confirmation to client&gt;.<p>- Deprecate fsync &amp; friends. If you don&#x27;t want to wait for the data to get committed, write in non-blocking mode and ignore the completion event.<p>Solving this problem in end-user applications is really hard - almost no applications implement atomic write on top of filesystems correctly. And they shouldn&#x27;t have to - this should be the job of the filesystem. The filesystem can do this much more safely, with better guarantees, better performance and better error handling. Modern filesystems already have journals - buggy reimplementions of journals in userland doesn&#x27;t help anyone. &quot;Do not turn off console while game is saving&quot; is an embarrassment to everyone.