bcache vs dm-cache: SSD Caching on Linux

SSDs are fast but expensive per gigabyte. HDDs are cheap but slow. Linux gives you two kernel-level tools to combine them: bcache and dm-cache. Both use an SSD as a transparent cache in front of a larger HDD, but they differ in architecture, setup requirements, and where they perform best.

How bcache Works

Bcache has been in the Linux kernel since version 3.10 (June 2013). It operates at the block layer, so it works with any filesystem that supports UUIDs.

Internally, bcache uses a hybrid B+ tree/log structure. It splits SSD storage into fixed-size buckets (128K to 2MB), aligned to erase block boundaries. This converts random writes into sequential ones, which reduces write amplification and extends SSD lifespan. Sequential I/O operations over 4MB automatically bypass the cache, keeping the SSD focused on the random access patterns where it adds the most value.

Bcache also monitors SSD latency in real time. If read latency exceeds 2ms or write latency passes 20ms, it throttles traffic to prevent the cache device from becoming a bottleneck.

Setup

Install bcache-tools, then format your backing device and cache device:

make-bcache -B /dev/sdb          # format HDD as backing device
make-bcache -C /dev/sdc          # format SSD as cache device
echo <UUID> > /sys/block/bcache0/bcache/attach   # attach cache

Runtime tuning happens through the /sys/block/bcache<N>/bcache/ sysfs interface, where you can adjust caching modes, sequential I/O thresholds, and latency targets. For RAID arrays, use --data-offset to align with your stripe width.

The catch: setup is destructive. Both devices must be formatted as bcache targets, so you cannot add bcache to an existing filesystem without wiping it first. Bcache devices also cannot be resized after creation.

Performance

Bcache's write consolidation gives it strong random write numbers. In benchmarks, it has reached roughly 18,500 random 4K write IOPS compared to 12,200 IOPS on the raw SSD alone. Random read throughput can reach approximately 1,000,000 IOPS with capable hardware.

For encrypted workloads, layer dm-crypt on top of the /dev/bcache<N> device rather than encrypting the underlying drives individually. This typically performs better because bcache can still consolidate writes before encryption.

How dm-cache Works

dm-cache is a Device Mapper target that sits above an existing logical volume. It uses three sub-devices: an origin device (HDD), a cache device (SSD or NVMe), and a metadata device that tracks block locations and dirty states. The default cache policy is smq (Stochastic Multi-Queue), which identifies hot data in mixed workloads.

The key advantage: dm-cache can be layered onto a live LVM volume without destroying existing data. You can also resize it using standard LVM commands.

Setup with LVM

The practical way to configure dm-cache is through lvmcache. Manual dmsetup configuration is possible but error-prone and does not survive reboots. The LVM approach:

1. Create Physical Volumes (PVs) on both the HDD and SSD.
2. Add both PVs to a single Volume Group (VG).
3. Create three Logical Volumes: one for backing data (HDD), one for cache (SSD), one for metadata (SSD).
4. Combine the cache and metadata LVs into a cache pool:
   lvconvert --type cache-pool --poolmetadata <meta_lv> <cache_lv>
5. Attach the pool to the origin:
   lvconvert --type cache --cachepool <pool_lv> <data_lv>

One thing to watch: mount the filesystem via its /dev/mapper/ path, not by UUID. Mounting by UUID can bypass the cache layer and hit the origin device directly.

Performance and memory

In writeback mode under a 90/10 read/write Zipf workload, dm-cache has achieved read speeds of about 193 MB/s and write speeds of roughly 21 MB/s. In another benchmark, caching a 100 GB HDD with a 10 GB NVMe partition increased random write IOPS from 118 to 798.

The trade-off is memory. dm-cache's metadata overhead depends on block size. A 512-byte block size can consume over 16 GB of RAM per 100 GB of cache. Bumping that to 4,096 bytes drops memory use to about 2 GB per 100 GB. Choose a block size close to your average I/O size (64 KB is a reasonable starting point) and make sure it is a multiple of 64 sectors (32 KB), within the 32 KB to 1 GB range.

Metadata is flushed on every FLUSH or FUA write, or at least once per second. For high availability, mirror the metadata device to avoid a single point of failure.

Caching Modes

Both bcache and dm-cache support the same core caching modes. The choice affects both performance and data safety.

Writethrough is the safe default for both tools. Writeback is faster but introduces real risk: if the SSD dies while holding unflushed data, that data is gone and the filesystem may be corrupted. Use writeback only when you have redundant SSDs or can tolerate occasional data loss.

bcache vs dm-cache: Which to Use

Use bcache when you are building a new system from scratch and want the best possible random I/O performance. It is the better choice for write-heavy workloads like databases and VM storage, and for RAID 6 arrays where random write penalties are severe.

Use dm-cache when you need to add caching to a server that is already in production. Its LVM integration means you can attach a cache without downtime or data migration. It is a better fit for read-heavy workloads and environments where you need the flexibility to resize or reconfigure storage on the fly.

Conclusion

Both tools solve the same problem, but they suit different situations. Bcache is the performance pick for fresh builds. dm-cache is the practical pick for existing LVM systems. Whichever you choose, start with writethrough mode until you are confident in your SSD reliability, then switch to writeback if you need the write performance.

If you need dedicated servers with SSD caching configurations, explore FDC's dedicated server options.