Summary: No — they are not rated the same. Looking across the community, lvmcache (dm-cache) is frequently favored for “LVM integration, operational ease, mature tooling, and production track record,” while bcache wins praise for “high performance under the right conditions and the flexibility to cache multiple HDDs with a single SSD.” Users who prioritize conservative, large-scale, stable operation tend to prefer lvmcache; users who want peak performance or one-SSD-to-many-HDD caching pick bcache.
-
Production / large-scale reports There are reports of 50–100 PB object storage run for 5+ years with lvmcache, and comments like “we tried bcache but lvmcache fit our workload better; the tooling is better” and “you can add cache without downtime if you already run LVM.” Operationally positive feedback for lvmcache is common.
-
Community impressions (individuals to small/medium setups) On Reddit comparison threads, opinions that “bcache has many regression bugs” coexist with counterarguments that it’s mature. For lvmcache, there are reports of “data remained usable when cache device failed (writethrough), and it was stable even under frequent power issues.” While opinions vary, stability praise skews toward lvmcache.
-
Distribution / official docs positioning SUSE documents both bcache and lvmcache as supported. They state bcache is “production-ready” and provide detailed steps for creating and managing lvmcache (dm-cache) under LVM. Both support write-through and write-back modes.
-
Performance takes (benchmarks & blog posts) Comparison articles show that bcache can reach higher IOPS under tuned conditions, while lvmcache behaves more predictably and warms up more gently when the cache is full. Recent blog posts sometimes describe hitting snags with bcache and ultimately switching to lvmcache for operational simplicity.
-
Policy defaults and “works out of the box” quality (lvmcache) dm-cache’s default policy smq is significantly better than the older mq, and many users note smq “just works” without heavy tuning.
-
Snapshots and related operational features (lvmcache) Historically there was concern that “LVs with cache could not snapshot,” but RHEL 7.5+ added support. Older negative information can be outdated.
-
Handling multiple devices bcache can use one SSD to cache multiple backends (HDDs); lvmcache / dm-cache cannot share one cache among multiple origins — a repeatedly noted architectural restriction. This is a common reason to prefer bcache.
-
Behavior on failure Both have risk when using write-back: cache device failure can cause data loss. The common recommendation is write-through or mirroring the cache. lvmcache has clear, documented commands such as lvconvert --splitcache / --uncache for safely removing cache devices.
| Axis | bcache | lvmcache (dm-cache) |
|---|---|---|
| Operational & tooling | More setup/initial integration work; environment differences can cause trouble. | Integrated in LVM; tooling is mature and easier to operate. |
| Production feedback | Enthusiasts cite high performance and flexibility, but concerns about regressions and recovery complexity appear. | Many reports of stable, long-term production use. |
| Performance feel | Can deliver higher throughput/IOPS if tuned and workload fits. | Default policy (smq) gives good results with predictable behavior. |
| Multi-device support | One SSD can cache multiple HDDs. | Not supported — design is 1 origin : 1 cache. |
| Snapshots & related features | Depends on higher-level setup. | Supported in modern RHEL/LVM (RHEL 7.5+); older neg info may be stale. |
| Safety / failure handling | Use write-through or mirror the cache (shared advice). | Same advice; plus clearly documented split/uncache procedures. |
Source: aggregated community posts and official docs. Main evidence in footnotes.
-
If you use LVM and want a conservative, reliable win: choose lvmcache. It integrates with existing LVM workflows, can be attached/detached without downtime, and the default smq policy usually performs well.
-
If you need one SSD to cache multiple HDDs, or you want to chase peak performance and can invest in tuning and recovery planning: choose bcache. The 1:many caching model is bcache’s advantage, but it assumes you can invest time in setup, tuning, and robust recovery processes.
-
If your workload is NAS-style large sequential transfers: Neither will give dramatic gains — focus on OS page cache and architecture first.
-
If failure tolerance is the top priority: use write-through or mirror the cache. Avoid relying solely on write-back without redundancy.
- Production lvmcache operational reports (tooling, hot-attachment).
- Reddit comparison threads (mixed opinions; stability praise for lvmcache).
- SUSE official docs (both supported; notes on bcache and dm-cache).
- Benchmarks and comparative writeups (bcache peaks; lvmcache predictability).
- Recent blog posts (operators switching from bcache to lvmcache).
- dm-cache policy (smq improvements over mq).
- Snapshot support for cached LVs (RHEL 7.5+).
- bcache 1:many caching and dm-cache 1:1 design limitation.
- Data-loss risk in write-back and mitigation advice.
Conclusion: Users do not rate bcache and lvmcache equally. The split is pragmatic: lvmcache is favored for operational simplicity and stable production use; bcache is chosen when flexibility (1 SSD → many HDDs) or squeezing more peak performance is the goal. Choose based on workload patterns, capacity ratios, and how much operational effort you can commit to tuning and recovery planning.