Are bcache and/or dm-cache considered stable for production in 2016?

Question

I would like to use linux SSD caching (dm-cache or bcache) with Debian Jessie production servers. (kernel 3.16)

My question: Are dm-cache and bcache modules reliables in linux 3.16 ? Do I need to upgrade my kernel to a more recent version ?

I also found this worrying message about bcache: https://lkml.org/lkml/2015/12/22/154

Notice that I totally understand what implies caching mode choices (write-back/write-through) in term of reliability and data-loss, my question is more about software bug in these modules

---

February 2018 follow up after more than 1 year of bcache on a continuous integration server (jenkins instance running lot of intensive jobs !)

Configuration of the server (storage stack essentially)

Hardware:

• 2 x 480GB SSD (Samsung SM863 enterprise grade MLC)
• 2 x 4TB HDD (Seagate Constellation ES.3 SATA)
• Dell R730 - Dual Xeon E52670 - 128GB RAM
• NO hardware RAID, no battery/flash backed hardware write bache, that's where the bcache's writeback feature becomes interesting.

Software:

• configured in September 2016, never rebooted
• Debian Jessie with 4.6 kernel (from official jessie-backport at the time of last update)
• software MD raid 10
  • 1 raid10 device for the 2 SSD
  • 1 raid10 device for the 2 HDD
• 2 LVM VG on top the 2 raid devices
• a bcache "caching" device created on a logical volume on the SSD_RAID10 VG
• a bcache "backing" device created on a logical volume on the HDD_RAID10 VG
• the bcache cache configured as writeback

Workload

• many jenkins jobs (continuous integration)
• cpu intensive jobs mixed with periods of I/O intensivity
  • before using bcache such periods where rising regularly the I/O average latency above 5 seconds (!!!)
• real workload on this server started only 1 year ago (~Feb 2017)

I/O amount issued on the bcache device according to /proc/diskstats)

• 350TB written
• 6TB read (I double checked that, I think that the large amount of RAM helps a lot to cache the reads in the VFS layer)

Result

• rock stable ! the machine never had to be rebooted (uptime 525 days), no corruption detected.
• hit rate is high ! 78% in all time average, and rising: above 80% in the last months
• writeback helps a lot: the disk latency is now order of magnitude lower, sadly I have not accurate measures for that, but the computations are not stalled anymore by write bursts. The dirty data amount rises above 5GB, where an hardware RAID writecache has usually a size between 512MB and 1GB )

Conclusion

• bcache is rock stable on this configuration ( but 1 machine, 1 configuration, 1 machine year, it is not sufficient to generalize but it is a good start !)
• bcache is very performant on this workload and the writeback mode seems to efficiently replace an hardware RAID write-cache (but keep in mind that the reliability on power loss has not been tested)
• in my personal opinion bcache is underrated, and interesting solution could be packaged using it but notice also that the original author now develops bcachefs (a filesytem based on is bcache work) and doesn't improve bcache anymore

Answer 1

I looked at your link and went through all the patches, and manually verified that each one was merged in vanilla kernel 4.9.0, with the last patch merged in on 2016-10-27 04:31:17 UTC. That last patch appeared in 4.9.0 released 2016-12-11 19:17:54 UTC. And all of them also appear in the 4.4 kernel available on Ubuntu 14.04 backported from 16.04, linux-lts-xenial_4.4.0-67.88.

And I would not focus too much on the "decreasing cost of SSD storage" since also HDD storage cost decreases too. You can still use both together to save money. Or instead of SSDs, you could get some NVMe instead, which is even faster.

And the rate of corruption from bugs might still not be zero, but even if there are bugs left, the rate is low enough that you don't have to worry if you have backups, which you should have regardless of whether you use caching or RAID.

Answer 2

I think that the decreasing cost of SSD storage and the increasing capacity and range of options available make a good case for use using solid-state storage where you need it and foregoing the idea of selective (and potentially buggy) caching.

If you fill in some detail about the environment, the capacity needs and anything else, it may help with a better answer.