<story><title>Linux&apos;s fsync() woes are getting some attention</title><url>http://rhaas.blogspot.com/2014/03/linuxs-fsync-woes-are-getting-some.html</url></story><parent_chain><item><author>bodyfour</author><text>I think part of the problem is that fsync() is that it&amp;#x27;s an insufficient interface.  Most of the time, you want two things:
  * write ordering (&amp;quot;write B must hit disk after write A&amp;quot;)
  * notification (&amp;quot;let me know when write A is on disk&amp;quot;)
In particular, you often &lt;i&gt;don&amp;#x27;t&lt;/i&gt; want to actually force I&amp;#x2F;O to happen immediately, since for performance reasons it&amp;#x27;s better for the kernel to buffer as much as it wants.  In other words, what you want should be nearly free, but instead you have to do a very expensive operation.&lt;p&gt;For an example for notification: suppose I have a temporary file with data that is being journaled into a data store.  The operation I want to do is:
  1. Apply changes to the store
  2. Wait until all of those writes hit disk
  3. Delete the temporary file
I don&amp;#x27;t care if step 2 takes 5 minutes, nor do I want the kernel to schedule my writes in any particular way.  If you implement step 2 as a fsync() (or fdatasync()) you&amp;#x27;re having a potentially huge impact on I&amp;#x2F;O throughput.  I&amp;#x27;ve seen these frequent fsync()s cause 50x performance drops!</text></item></parent_chain><comment><author>dap</author><text>&amp;gt; In particular, you often don&amp;#x27;t want to actually force I&amp;#x2F;O to happen immediately, since for performance reasons it&amp;#x27;s better for the kernel to buffer as much as it wants.&lt;p&gt;If you don&amp;#x27;t issue an fsync(), the kernel never has to write anything.  If you had a different function that did what you suggest, returning when the kernel had decided to write the data (without instructing the kernel to do so soonish), you could literally be waiting forever.  If the function ever returned, it would only be because something else on the system asked for a sync (and it was easier to write everything), or because you&amp;#x27;re operating on a filesystem that chooses to write data sooner than required.  Both of these are basically working by accident (i.e., may well not work on other POSIX systems).&lt;p&gt;I think what you really want is to instruct the kernel that this data should be written out, and you want to block until that happens.  That&amp;#x27;s exactly what fsync() is supposed to do.  The fact that some kernels hammer the I&amp;#x2F;O subsystem while doing so is a bug in those kernels, not the fsync() interface.</text></comment>
<story><title>Linux&apos;s fsync() woes are getting some attention</title><url>http://rhaas.blogspot.com/2014/03/linuxs-fsync-woes-are-getting-some.html</url></story><parent_chain><item><author>bodyfour</author><text>I think part of the problem is that fsync() is that it&amp;#x27;s an insufficient interface.  Most of the time, you want two things:
  * write ordering (&amp;quot;write B must hit disk after write A&amp;quot;)
  * notification (&amp;quot;let me know when write A is on disk&amp;quot;)
In particular, you often &lt;i&gt;don&amp;#x27;t&lt;/i&gt; want to actually force I&amp;#x2F;O to happen immediately, since for performance reasons it&amp;#x27;s better for the kernel to buffer as much as it wants.  In other words, what you want should be nearly free, but instead you have to do a very expensive operation.&lt;p&gt;For an example for notification: suppose I have a temporary file with data that is being journaled into a data store.  The operation I want to do is:
  1. Apply changes to the store
  2. Wait until all of those writes hit disk
  3. Delete the temporary file
I don&amp;#x27;t care if step 2 takes 5 minutes, nor do I want the kernel to schedule my writes in any particular way.  If you implement step 2 as a fsync() (or fdatasync()) you&amp;#x27;re having a potentially huge impact on I&amp;#x2F;O throughput.  I&amp;#x27;ve seen these frequent fsync()s cause 50x performance drops!</text></item></parent_chain><comment><author>Qantourisc</author><text>Not a kernel dev but to my knowledge &amp;quot;write B must hit disk after write A&amp;quot; would actually be rather easy to implement: if the storage device supports it: insert a write barrier.
For the &amp;quot;let me know when write A is on disk&amp;quot; adding a callback to a write-barrier would do, not sure what the kernel queue looks like though.</text></comment>