lkml.org 
[lkml]   [2015]   [Apr]   [29]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    SubjectRe: Tux3 Report: How fast can we fsync?
    Date
    Daniel Phillips <daniel@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@mail.parknet.co.jp>


    \
     
     \ /
      Last update: 2015-04-30 01:01    [W:3.224 / U:0.076 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site