Hacker News Reader

Comment by wscott | Hacker News Reader

He doesn't really mention how this relates to the current bcache code. That one is brilliant. I run a 4 drive raid with slow spinning 2TB drives and a 100G SSD drive as a writeback cache top. It detects strides so reading and writing large files stream directly to the raid, but little reads and writes got via the SSD. By filtering all the little traffic, the actual traffic to the drives is more efficient and spends less time seeking. In that setup bcache effectively creates a cached block device and I format that with ext4. It seems now it includes the filesystem. Not sure I like that, but it seems to be the trend in filesystems since ZFS.

View on HN

He mentions multiple times in the first few paragraphs that this is an evolution of the current bcache code:

"For those who haven't kept up with bcache, the bcache codebase has been evolving/metastasizing into a full blown, general purpose posix filesystem... I and the other people working on bcache realized that what we were working on was, almost by accident, a good chunk of the functionality of a full blown filesystem - and there was a really clean and elegant design to be had there if we took it and ran with it."

I've been considering using bcache on one of my systems, last time I checked it seemed a bit unready in terms of all the steps needed to set it up and keep it working. What has your experience been?

I've run bcache-backed databases in production for about a year or so - it's been absolutely rock solid, and I'm very happy with it.

We spent a lot of time prototyping basically every SSD caching tech that existed at the time and bcache was the clear winner (note that dm-cache, the tech underpinning lvm-cache was pretty immature at the time).

You do need a workload with a fairly reasonable cache hitrate to get the best out of it, but that's obviously true of all such technologies.

I'm afraid I still see little bugs appearing on the mailing list and on my test systems.

For bugs look at: https://github.com/koverstreet/linux-bcache/issues http://dir.gmane.org/gmane.linux.kernel.bcache.devel

You should definitely consider/test dm-cache too...

https://www.redhat.com/archives/dm-devel/2013-June/msg00026....

https://www.varnish-software.com/blog/accelerating-your-hdd-...

I have lost data, twice in the last six months.

Is your SSD similar to L2ARC in ZFS?

Yes, see the "What is bcache?" section here: http://bcache.evilpiepirate.org/ He compares it to L2ARC... same but with writeback. (ie writes can be considered finished when they are recorded by the SSD. Faster but less safe unless your SSD is also a raid.)

The bcachefs part at the top of that page is the new stuff this announcement is describing.

Ok, so it is a combination of L2ARC and ZIL (zfs intent log), then?

L2ARC improves read operations, ZIL improves writes.

It's neither. It's just a writeback cache, that gets bypassed for sequential operations.

Reply on news.ycombinator.com