Re: Give up on bcache?

["Austin S. Hemmelgarn" <ahferroin7@gmail.com>]

On 2017-09-26 12:50, Ferry Toth wrote:
> Looking at the Phoronix benchmark here:
> 
> https://www.phoronix.com/scan.php?page=article&item=linux414-bcache-
> raid&num=2
> 
> I think it might be idle hopes to think bcache can be used as a ssd cache
> for btrfs to significantly improve performance.. True, the benchmark is
> using ext.
It's a benchmark.  They're inherently synthetic and workload specific, 
and therefore should not be trusted to represent things accurately for 
arbitrary use cases.
> 
> But the most important one (where btrfs always shows to be a little slow)
> would be the SQLLite test. And with ext at least performance _degrades_
> except for the Writeback mode, and even there is nowhere near what the
> SSD is capable of.
And what makes you think it will be?  You're using it as a hot-data 
cache, not a dedicated write-back cache, and you have the overhead from 
bcache itself too.  Just some simple math based on examining the bcache 
code suggests you can't get better than about 98% of the SSD's 
performance if you're lucky, and I'd guess it's more like 80% most of 
the time.
> 
> I think with btrfs it will be even worse and that it is a fundamental
> problem: caching is complex and the cache can not how how the data on the
> fs is used.
Actually, the improvement from using bcache with BTRFS is higher 
proportionate to the baseline of not using it by a small margin than it 
is when used with ext4.  BTRFS does a lot more with the disk, so you 
have a lot more time spent accessing the disk, and thus more time that 
can be reduced by improving disk performance.  While the CoW nature of 
BTRFS does somewhat mitigate the performance improvement from using 
bcache, it does not completely negate it.
> 
> I think the original idea of hot data tracking has a much better chance
> to significantly improve performance. This of course as the SSD's and
> HDD's then will be equal citizens and btrfs itself gets to decide on
> which drive the data is best stored.
First, the user needs to decide, not BTRFS (at least, by default, BTRFS 
should not be involved in the decision).  Second, tiered storage (that's 
what that's properly called) is mostly orthogonal to caching (though 
bcache and dm-cache behave like tiered storage once the cache is warmed).
> 
> With this implemented right, it would also finally silence the never
> ending discussion why not btrfs and why zfs, ext, xfs etc. Which would be
> a plus by its own right.
Even with this, there would still be plenty of reasons to pick one of 
those filesystems over BTRFS.  There would however be one more reason to 
pick BTRFS over ext or XFS (but necessarily not ZFS, it already has 
caching built in).