Testing FusionIO: strict_sync is too strict…

With new updates of FusionIO drivers I was able to test it on our Dell R900 with Ubuntu 8.10 without pain of compiling drives myself and downgrading to older kernel, so I was decided to test it in strict_sync mode.

As I understand FusionIO in default mode, like Intel SSD, is “lying” to application, and fsync() is not real, it still commit only to internal memory, not to final media. And FusionIO has “strict_sync” mode to guarantee fsync is trustworthy.

So let’s benchmark it – as usually I do tpcc-mysql benchmark on 100W (9GB data) with 3GB buffer_pool in O_DIRECT access.

The raw number are here

and graph is
Results are in TPM (Transactions Per Minute), more is better, and graph shows how result is changing in time ( axis X ).
It is too obvious from graph to comment it…

I actually did not test if you really loose transactions in case of power outage in default mode, this is something to check.

Share this post

Comments (8)

  • Didier Spezia

    A pity they do not provide an optional BBU for this kind of hardware …

    June 16, 2009 at 5:41 am
  • Andrea

    unbelievably low number of tpm!

    June 16, 2009 at 6:31 am
  • Andy

    The tpm does look unbelievably low.

    According to this benchmark:
    A lowly PC with 2 SATA disk running software RAID 0 is getting around 3,000 tpm in tpcc-mysql.

    That’s more than what you got using FusionIO.

    So a $10K FusionIO capable of 100K IOPS is outperformed by two $50 SATA drives in SW RAID 0???

    Something’s not right.

    June 17, 2009 at 3:36 am
  • Vadim


    Mark may have used absolutely different setting for InnoDB and benchmarks, so results are not comparable in any way.

    June 17, 2009 at 11:44 am
  • peter

    Didier Spezia,

    This also surprises me. $500 RAID cards have BBU on them. I think it should not cost more than $100 to provide BBU and same as for RAID card it should be possible to have it as an option but neither FusionIO nor any SSDs I know provide is an an option.

    Probably lying is good enough for most of users 🙂

    June 17, 2009 at 3:07 pm
  • Stephan Uphoff


    I expect that our next release will no longer require the strict_sync setting for durability (without any performance loss)
    I am surprised about the low throughput – with or without strict_sync – are you testing with a single thread ? (Even for that it seems to be very slow)
    Can you describe your test setup?

    Currently with strict_sync on I recommend writing large blocks using at least two threads for writing (unless they are serialized by a file lock anyway).
    For strict-sync you can think of the sync writes as participating in group commits that are either triggered by reaching a certain combined size (depending on card – should be smaller than 128K in your case) or a timeout.
    Unfortunately the last write that reaches the combined “group commit” size will overflow into the next “group commit”.

    Hope this helps and again – strict_sync should no longer be required in the near future.


    June 18, 2009 at 7:01 am
  • Vadim


    It’s would be amazing if we will be able to rely on fsync without strict_sync and with the same performance!

    I am testing tpcc-like benchmark. You can see more details about setup in this post.

    In this benchmark I use 32 connection to mysql, but mysql settings are

    so final concurrency on device may be different.

    Please let me know when strict_sync is not be needed, I will re-test it.

    Currently we can’t recommend FusionIO to customers who have strong durability requirements.

    June 18, 2009 at 9:14 am
  • Sumeet Bansal

    Hello Vadim,

    I am the Principal Solutions Architect at Fusion-io. I focus on Database systems integration with Fusion-io.

    We have made some improvements in our latest drives that allow us to flush in-flight data. Your feedback is very crucial for us and I would like to enlist your help in re-testing our product without strict_sync and simulating power loss scenarios to ascertain that there is no corruption or data loss. If you are willing to something like this, please email me at sumeet@fusionio.com




    November 13, 2009 at 11:49 am

Comments are closed.

Use Percona's Technical Forum to ask any follow-up questions on this blog topic.