Re: Tux3 Report: How fast can we fsync?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Daniel Phillips <daniel@xxxxxxxxx> 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@xxxxxxxxxxxxxxxxxx>
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[Index of Archives]     [Linux Ext4 Filesystem]     [Union Filesystem]     [Filesystem Testing]     [Ceph Users]     [Ecryptfs]     [AutoFS]     [Kernel Newbies]     [Share Photos]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux Cachefs]     [Reiser Filesystem]     [Linux RAID]     [Samba]     [Device Mapper]     [CEPH Development]
  Powered by Linux