On Wed, Aug 16, 2017 at 8:01 AM, Qu Wenruo [off-list ref] wrote:

BTW, when Fujitsu tested the postgresql workload on btrfs, the result is
quite interesting.

For HDD, when number of clients is low, btrfs shows obvious performance
drop.
And the problem seems to be mandatory metadata COW, which leads to
superblock FUA updates.
And when number of clients grow, difference between btrfs and other fses
gets much smaller, the bottleneck is the HDD itself.

While for SSD, when number of clients is low, btrfs is almost the same
performance as other fses, nodatacow/nodatasum only provides marginal
difference.
But when number of clients grows, btrfs falls far behind other fses.
The reason seems to be related to how postgresql commit its transaction,
which always fsync its journal sequentially without concurrency.

I wonder to what degree fsync is used as a hammer for a problem that
needs more granular indicators to solve, like fsadvise() and even
extending it?

But I'm also curious if the above behaviors you report, how it changes
by combining SSD and HDD via either dm-cache or bcache? Do the worst
aspects of SSD and HDD get muted in that case? Or do the worst aspects
become even worse across the board?


-- 
Chris Murphy