Tux3 Report: Faster than tmpfs, what?

[Daniel Phillips]

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

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.

Regards,

Daniel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://phunq.net/pipermail/tux3/attachments/20130511/690c1dae/attachment.html>