<p dir="ltr"><br>
On May 11, 2013 2:26 PM, "Theodore Ts'o" <<a href="mailto:tytso@mit.edu">tytso@mit.edu</a>> wrote:<br>
><br>
> On Fri, May 10, 2013 at 11:12:27PM -0700, Daniel Phillips wrote:<br>
> > Hi Dave,<br>
> ><br>
> > Thanks for the catch - I should indeed have noted that "modified<br>
> > dbench" was used for this benchmark, thus amplifying Tux3's advantage<br>
> > in delete performance.<br>
><br>
> Dropping fsync() does a lot more than "amplify Tux3's advantage in<br>
> delete performace".  Since fsync(2) is defined as not returning until<br>
> the data written to the file descriptor is flushed out to stable<br>
> storage --- so it is guaranteed to be seen after a system crash --- it<br>
> means that the foreground application must not continue until the data<br>
> is written by Tux3's back-end.<br>
><br>
> So it also means that any advantage of decoupling the front/back end<br>
> is nullified, since fsync(2) requires a temporal coupling.  In fact,<br>
> if there is any delays introdued between when the front-end sends the<br>
> fsync request, and when the back-end finishes writing the data and<br>
> then communicates this back to the front-end --- i.e., caused by<br>
> schedular latencies, this may end up being a disadvantage compared to<br>
> more traditional file system designs.<br>
><br>
> Like many things in file system design, there are tradeoffs.  It's<br>
> perhaps more quseful when having these discussions to be clear what<br>
> you are trading off for what; in this case, the front/back design may<br>
> be good for somethings, and less good for others, such as mail server<br>
> workloads where fsync(2) semantics is extremely important for<br>
> application correctness.</p>
<p dir="ltr">Exactly, Ted. We avoided measuring the fsync load on this particular benchmark because we have not yet optimized fsync. When we do get to it (not an immediate priority) I expect we will perform competitively, because Tux3 does manage to get deltas onto disk with a minimal number of block writes.</p>

<p dir="ltr">Regards,</p>
<p dir="ltr">Daniel<br>
</p>