Tux3 Report: How fast can we fsync?

[OGAWA Hirofumi]

Daniel Phillips <daniel at phunq.net> writes:

> On Wednesday, April 29, 2015 9:42:43 AM PDT, Mike Galbraith wrote:
>>
>> [dbench bakeoff]
>>
>> With dbench v4.00, tux3 seems to be king of the max_latency hill, but
>> btrfs took throughput on my box.  With v3.04, tux3 took 1st place at
>> splashing about in pagecache, but last place at dbench -S.
>>
>> Hohum, curiosity satisfied.
>
> Thanks for that. Please keep in mind, that was our B team, it does a
> full fs sync for every fsync. Maybe a rematch when the shiny new one
> lands? Also, hardware? It looks like a single 7200 RPM disk, but it
> would be nice to know. And it seems, not all dbench 4.0 are equal.
> Mine doesn't have a -B option.

Yeah, I also want to know hardware. Also, what size of partition?  And
each test was done by fresh FS (i.e. after mkfs), or same FS was used
through all tests?

My "hirofumi" branch in public repo is still having the bug to leave the
empty block for inodes by repeat of create and unlink. And this bug
makes fragment of FS very fast. (This bug is what I'm fixing, now.)

If same FS was used, your test might hit to this bug.

Thanks.
-- 
OGAWA Hirofumi <hirofumi at mail.parknet.co.jp>