[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <a50cab4e-1547-47f7-b280-b84a2cdb8d0d@phunq.net>
Date: Wed, 29 Apr 2015 13:40:22 -0700
From: Daniel Phillips <daniel@...nq.net>
To: Mike Galbraith <umgwanakikbuti@...il.com>
Cc: <linux-kernel@...r.kernel.org>, <linux-fsdevel@...r.kernel.org>,
<tux3@...3.org>, Theodore Ts'o <tytso@....edu>,
OGAWA Hirofumi <hirofumi@...l.parknet.co.jp>
Subject: Re: Tux3 Report: How fast can we fsync?
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.
Hi Mike,
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.
That order of magnitude latency difference is striking. It sounds
good, but what does it mean? I see a smaller difference here, maybe
because of running under KVM.
Your results seem to confirm the gap I noticed between Ext4 and XFS
on the one hand and Btrfs and Tux3 on the other, with the caveat that
the anomalous dbench -S result is probably about running with the
older fsync code. Of course, this is just dbench, but maybe something
to keep an eye on.
Regards,
Daniel
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists