Hubbry Logo
BcacheBcacheMain
Open search
Bcache
Community hub
Bcache
logo
7 pages, 0 posts
0 subscribers
Be the first to start a discussion here.
Be the first to start a discussion here.
Bcache
Bcache
Bcache
View on Wikipedia
from Wikipedia

bcache
DevelopersKent Overstreet and others
Initial releaseJune 30, 2013; 12 years ago (2013-06-30) (Linux 3.10)
Repository
Written inC
Operating systemLinux
TypeLinux kernel features
LicenseGNU GPL
Websitebcache.evilpiepirate.org

bcache (abbreviated from block cache) is a cache mechanism in the Linux kernel's block layer, which is used for accessing secondary storage devices. It allows one or more fast storage devices, such as flash-based solid-state drives (SSDs), to act as a cache for one or more slower storage devices, such as hard disk drives (HDDs); this effectively creates hybrid volumes and provides performance improvements.

Designed around the nature and performance characteristics of SSDs, bcache also minimizes write amplification by avoiding random writes and turning them into sequential writes instead. This merging of I/O operations is performed for both the cache and the primary storage, helping in extending the lifetime of flash-based devices used as caches, and in improving the performance of write-sensitive primary storages, such as RAID 5 sets.

bcache is licensed under the GNU General Public License (GPL), and Kent Overstreet is its primary developer. Overstreet considers bcache as a "prototype" for the development of bcachefs, a filesystem with significant improvements over bcache.[1]

Overview

[edit]

Using bcache makes it possible to have SSDs as another level of indirection within the data storage access paths, resulting in improved overall performance by using fast flash-based SSDs as caches for slower mechanical hard disk drives (HDDs) with rotational magnetic media. That way, the gap between SSDs and HDDs can be bridged – the costly speed of SSDs gets combined with the cheap storage capacity of traditional HDDs.[2]

Caching is implemented by using SSDs for storing data associated with performed random reads and random writes, using near-zero seek times as the most prominent feature of SSDs. Sequential I/O is not cached, to avoid rapid SSD cache invalidation on such operations that are already suitable enough for HDDs; going around the cache for big sequential writes is known as the write-around policy. Not caching the sequential I/O also helps in extending the lifetime of SSDs used as caches.[3] Write amplification is avoided by not performing random writes to SSDs; instead, all random writes to SSD caches are always combined into block-level writes, ending up with rewriting only the complete erase blocks on SSDs.[4][5]

Both write-back and write-through (which is the default) policies are supported for caching write operations. In case of the write-back policy, written data is stored inside the SSD caches first, and propagated to the HDDs later in a batched way while performing seek-friendly operations – making bcache to act also as an I/O scheduler. For the write-through policy, which ensures that no write operation is marked as finished until the data requested to be written has reached both SSDs and HDDs, performance improvements are reduced by effectively performing only caching of the written data.[4][5]

Write-back policy with batched writes to HDDs provides additional benefits to write-sensitive redundant array of independent disks (RAID) layouts such as RAID 5 and RAID 6, which perform actual write operations as atomic read-modify-write sequences. That way, performance penalties[6] of small random writes are reduced or avoided for such RAID layouts, by grouping them together and performing as batched sequential writes.[4][5]

Caching performed by bcache operates at the block device level, making itself file system–agnostic as long as the file system provides an embedded universally unique identifier (UUID); this requirement is satisfied by virtually all standard Linux file systems, as well as by swap partitions. Sizes of the logical blocks used internally by bcache as caching extents can go down to the size of a single HDD sector.[7]

History

[edit]

bcache was first announced by Kent Overstreet in July 2010, as a completely working Linux kernel module, though at its early beta stage.[8] The development continued for almost two years, until May 2012, at which point bcache reached its production-ready state.[5]

It was merged into the Linux kernel mainline in kernel version 3.10, released on June 30, 2013.[9][10] Overstreet has since been developing the file system bcachefs, based on ideas first developed in bcache that he said began "evolving ... into a full blown, general-purpose POSIX filesystem".[11] He describes bcache as a "prototype" for the ideas that became bcachefs and intends bcachefs to replace bcache.[12] He officially announced bcachefs in 2015 and got it merged into the mainline Linux kernel in October 2023,[13] however in June 2025, Linus Torvalds announced that bcachefs would be dropped from the mainline Linux kernel by version 6.17, following tensions between Torvalds and Overstreet.[14][15]

Features

[edit]

As of version 3.10 of the Linux kernel, the following features are provided by bcache:[4]

  • The same cache device can be used for caching an arbitrary number of the primary storage devices
  • Runtime attaching and detaching of primary storage devices from their caches, while mounted and in use (running in passthrough mode when not cached)
  • Automated recovery from unclean shutdowns – writes are not completed until the cache is consistent with respect to the primary storage device; internally, bcache makes no distinction between clean and unclean shutdowns
  • Transparent handling of I/O errors generated by the cache devices[3]
  • Write barriers and associated cache flushes are properly handled
  • Write-through (which is the default), write-back and write-around policies
  • Sequential I/O is detected and bypassed, with configurable thresholds; bypassing can also be disabled
  • Throttling of the I/O to the SSD if it becomes congested, as detected by measured latency of the SSD's I/O operations exceeding a configurable threshold; useful for configurations having one SSD providing caching for many HDDs
  • Readahead on a cache miss (disabled by default)
  • Highly efficient write-back implementation – dirty data is always written out in sorted order, and optionally background write-back is smoothly throttled down to keeping configured percentage of the cache dirty
  • High-performance B+ trees are used internally – bcache is capable of around 1,000,000 IOPS on random reads, if the hardware is fast enough
  • Various runtime statistics and configuration options are exposed through sysfs[3]

Improvements

[edit]

As of February 2014, the following new features are planned for the future releases of bcache:[10]

  • Awareness of data striping in RAID 5 and RAID 6 layouts – adding awareness of the stripe layout to the write-back policy, so decisions on caching will be giving preference to already "dirty" stripes, and actual background flushes will be writing out complete stripes first
  • Handling cache misses with already full B+ tree nodes – as of the bcache version in Linux kernel 3.10, splits of the internally used B+ tree nodes happen on writes, making initial cache warm-ups hardly achievable
  • Multiple SSDs in a cache set – only dirty data (for the write-back policy) and metadata would be mirrored, without wasting SSD space for the clean data and read caches
  • Data checksumming

See also

[edit]
  • dm-cache – a Linux kernel's device mapper target that allows creation of hybrid volumes
  • EnhanceIO – a disk cache module for the Linux kernel.
  • Flashcache – a disk cache component for the Linux kernel, initially developed by Facebook
  • Hybrid drive – a storage device that combines flash-based and spinning magnetic media storage technologies
  • ReadyBoost – a disk caching software component of Windows Vista and later Microsoft operating systems
  • Smart Response Technology (SRT) – a proprietary disk storage caching mechanism, developed by Intel for its chipsets

References

[edit]
[edit]
Revisions and contributorsEdit on WikipediaRead on Wikipedia

Bcache

View on Grokipedia
from Grokipedia
Bcache is a block layer cache subsystem integrated into the , designed to accelerate operations by using faster storage devices, such as solid-state drives (SSDs), to cache data from slower underlying block devices like hard disk drives (HDDs) or arrays. Developed by Kent Overstreet, it was first merged into the mainline in version 3.10 in 2013, providing a filesystem-agnostic solution that operates at the block level to enhance performance without requiring changes to upper-layer software. The primary purpose of bcache is to bridge the speed gap between expensive, high-capacity HDDs and cost-effective SSD caching, enabling systems ranging from desktops to enterprise storage arrays to achieve significantly higher for frequently accessed data. It supports multiple caching modes, including writethrough (where writes are sent synchronously to both the cache and backing devices), writeback (for higher by caching writes before flushing to the backing ), and writearound (bypassing the cache for sequential writes). Key features include dynamic attachment and detachment of cache devices at runtime, support for multiple backing devices per cache set, and intelligent IO detection that skips sequential reads and writes to preserve SSD lifespan by minimizing random operations and . Bcache employs a hybrid and journal structure for efficient metadata management, allocating data in erase block-sized buckets to optimize SSD , and it ensures during unclean shutdowns through barriers, flushes, and automatic recovery mechanisms. Performance benchmarks have demonstrated capabilities up to 1 million for random reads, with random write throughput reaching 18.5K in early tests, outperforming direct SSD access in certain workloads. Configuration and monitoring occur via interfaces, allowing fine-tuned control over cache behavior, error handling (such as disabling caching on unrecoverable errors), and statistics, making it suitable for production environments. While bcache has influenced subsequent developments like the filesystem, it remains a standalone caching tool focused on block-level acceleration.

Introduction

Definition and Purpose

Bcache, short for block cache, is a cache mechanism integrated into the kernel's block layer, enabling the use of fast storage devices such as solid-state drives (SSDs) to serve as a read/write cache for slower secondary storage devices like hard disk drives (HDDs). This design operates at the block level, intercepting I/O requests to the backing storage and managing data placement transparently without requiring modifications to the filesystem or applications. The primary purpose of bcache is to enhance (I/O) performance, particularly for patterns common in mixed workloads, by storing frequently accessed data on high-speed caching media while retaining the larger capacity of slower devices. It facilitates the creation of hybrid storage volumes that leverage the speed of SSDs for latency-sensitive operations and the cost-efficiency of HDDs for bulk storage, thereby reducing overall system latency and improving throughput for applications like or virtual machines. By prioritizing caching of hot data on faster tiers, bcache optimizes resource utilization in environments where full SSD replacement would be prohibitively expensive. Key benefits of bcache include its cost-effective approach to storage tiering, allowing organizations to augment existing HDD with smaller, affordable SSDs rather than overprovisioning expensive all-flash arrays. Additionally, its block-level granularity avoids the overhead associated with filesystem-level caching, enabling efficient handling of diverse I/O patterns while supporting modes such as writethrough and writeback for flexible consistency trade-offs. This results in significant performance gains, such as up to several times higher for random reads compared to uncached HDDs alone.

Basic Operation

Bcache functions as a block-layer cache in the , intercepting I/O requests to a backing device and managing data flow between it and a faster cache device, such as an SSD, in a manner transparent to upper-layer filesystems. This setup allows hybrid storage configurations where the cache accelerates access to frequently used data blocks on slower, higher-capacity backing storage like HDDs or arrays. For read operations, bcache first checks the cache for the requested blocks. On a cache hit, the is served directly from the cache device, providing low-latency access. In the case of a cache , the requested blocks are retrieved from the backing device, and—unless the I/O is detected as sequential (with a default cutoff of 4 MB)—they are then populated into the cache for future use. This read-ahead mechanism helps populate the cache proactively while avoiding unnecessary caching of large sequential reads that would not benefit from the cache's speed. Write operations in bcache support two primary modes: writethrough and writeback. In writethrough mode, incoming writes are synchronously applied to both the cache and the backing device, ensuring data consistency without buffering dirty in the cache. Conversely, in writeback mode (which is disabled by default but can be enabled at runtime), writes are initially directed only to the cache for immediate acknowledgment, with the dirty later flushed asynchronously and sequentially to the backing device to maintain . This writeback approach enhances write by leveraging the cache's speed, though it introduces a brief window of potential in case of cache failure. Cache population and are managed using least-recently-used (LRU)-like heuristics to track and prioritize extents in metadata structures, ensuring efficient use of limited cache space. When the cache fills, less recently accessed blocks are to make room for new , while metadata persistently records which extents are cached on the backing device. Sequential I/O, both reads and writes, is typically bypassed to optimize for patterns common in workloads benefiting from caching.

History and Development

Origins and Initial Release

Bcache was primarily developed by Kent Overstreet, who announced the project on July 2, 2010, through an article on LWN.net detailing its design as a Linux kernel block layer cache for improving block device performance using solid-state drives (SSDs). The early development of bcache was driven by the growing availability of SSDs in the late 2000s and the need for an efficient, general-purpose caching solution within the Linux kernel that could accelerate slower storage devices without requiring modifications to existing filesystems. Initial prototypes emphasized integration at the block layer, ensuring independence from specific filesystem implementations to allow broad compatibility across Linux storage stacks. Pre-release discussions and patch sets were shared extensively on the (LKML) and Overstreet's personal website, bcache.evilpiepirate.org, where documentation, code repositories, and wikis facilitated community feedback and iterative improvements over the following years. Bcache achieved production-ready status in May 2012 with the release of version 13, as declared by Overstreet, marking it stable for real-world deployment as an out-of-tree kernel module. Its first official inclusion in the mainline occurred in version 3.10, released on June 30, 2013.

Kernel Integration and Evolution

Bcache was integrated into the mainline Linux kernel with version 3.10, released on June 30, 2013, enabling its use as a stable block caching mechanism without requiring external modules. This merge marked bcache's transition from an out-of-tree project to a core kernel component, and it has remained available in all subsequent kernel releases without major deprecations or removals. Following its integration, bcache underwent incremental enhancements focused on stability and performance across kernel versions up to the 6.x series. These updates included optimizations for better I/O handling and compatibility with emerging storage technologies, such as support for NVMe SSDs as caching devices once kernel NVMe drivers matured around version 3.13. In 2017, Coly Li was appointed as co-maintainer to support ongoing development and stability improvements. Such evolutions ensured bcache's reliability in diverse environments, with ongoing refinements addressing edge cases in block layer interactions. Bcache's development trajectory is linked to the bcachefs filesystem, a successor project led by the same primary developer, Kent Overstreet, which aimed to extend bcache's caching concepts into a full filesystem. was merged into the 6.7 development cycle in October 2023, with the kernel released on January 7, 2024, but faced significant challenges related to stability and maintenance disputes, leading to its designation as externally maintained in kernel 6.17 (released September 28, 2025) and complete removal committed for kernel 6.18 (expected release late 2025). This outcome reinforced bcache's position as the primary, mature caching solution within the kernel. As of November 2025, bcache remains stable and actively maintained in versions 6.12 and later, with no major rewrites planned but continued bug fixes integrated through standard kernel development channels, including patches for issues like dereferences in cache flushing routines. Its enduring presence underscores its role as a dependable tool for SSD caching in production systems.

Technical Architecture

Components

Bcache consists of several core hardware and software elements that form the foundation of its caching mechanism. The primary components include the backing device, the caching device, the superblock for metadata management, and the integration with the kernel's I/O path. The backing device serves as the slower, high-capacity storage layer that maintains the persistent data in a bcache setup. Typically implemented using hard disk drives (HDDs) or arrays, it provides the bulk storage for the filesystem or data volumes, while allowing faster caching to accelerate access. This device can function independently in passthrough mode without an attached cache, ensuring data availability even if caching is disabled. For example, a large HDD array might be designated as the backing device to store terabytes of data, with bcache handling the overlay of cached portions transparently. The caching device, in contrast, is a faster storage medium dedicated to holding frequently accessed to improve . Common examples include solid-state drives (SSDs) or NVMe devices, which offer low-latency reads and writes compared to the backing device. The caching device is typically smaller in capacity than the backing device, as it acts solely as an accelerator rather than a full replacement. Multiple caching devices can be combined into a cache set to distribute load and enhance reliability, supporting modes like writethrough or writeback for handling. Both the backing and caching devices rely on a superblock, a critical metadata structure that enables their registration and coordination within bcache. Located at an 8 KiB offset on the backing device and similarly on the caching device, the superblock stores essential information such as device UUIDs for identification, cache configuration parameters, and version details to ensure compatibility. This structure is vital for attaching devices to a cache set and recovering data integrity, as it allows the kernel to recognize and validate bcache-formatted devices during boot or reconfiguration. At the software level, bcache integrates into the kernel's block layer by registering the combined backing and caching setup as a single block device, such as /dev/bcache<N>. This allows it to intercept I/O requests through the kernel's request queues, transparently routing reads and writes to the appropriate component—cache for hits or backing device for misses—without altering the upper-layer filesystem's view. The integration occurs via interfaces at /sys/block/bcache<N>/bcache and /sys/fs/bcache/<UUID>, enabling runtime control and monitoring of the I/O path.

Data Management

Bcache employs a B+ tree structure as its primary on-disk index to map cached extents from the backing device to their locations in the cache. This structure efficiently tracks data ranging from single sectors up to full bucket sizes, with btree nodes indexing large regions of the cache. To support efficient updates, bcache uses a hybrid btree/log mechanism, where recent changes are first appended to a log before being incorporated into the btree, minimizing random writes to the cache device. The cache device is divided into buckets sized to match SSD erase blocks, typically ranging from 128 KB to 1 MB, to align with flash storage characteristics and reduce . Buckets are allocated sequentially and filled before reuse; upon invalidation, entire buckets are discarded rather than partially overwritten, ensuring predictable . This approach avoids the fragmentation and performance degradation associated with smaller, misaligned allocations on solid-state media. Metadata management in bcache relies on a journal to record recent modifications to the and cache state, with writes delayed up to 100 milliseconds by default (configurable via the journal_delay_ms ) to batch operations and improve efficiency. is classified into priority tiers based on access frequency, using recency statistics to distinguish hot (frequently accessed) from cold (infrequently used); these priorities influence eviction decisions, with hotter retained longer in the cache. The priority_stats interface provides metrics such as unused percentage and average priority to monitor behavior. Garbage collection periodically frees invalidated buckets by scanning and discarding obsolete , triggered manually via the trigger_gc entry or automatically under low free space conditions, ensuring sustained cache availability. For error resilience, bcache replays the journal upon mounting to recover from crashes or unclean shutdowns, reconstructing the state without a formal clean shutdown protocol. It handles I/O errors from the cache device by invalidating affected data and falling back to the backing device, with configurable error thresholds to disable caching if failures exceed limits. However, bcache lacks built-in checksumming for cached , instead relying on the error detection capabilities of the underlying storage devices.

Features and Capabilities

Caching Policies

Bcache employs several configurable caching policies to manage data placement and I/O operations between the cache device (typically an SSD) and the backing device (such as an HDD), balancing performance, safety, and device wear. These policies determine whether writes are cached, how reads are handled on misses, and when to bypass caching for specific patterns like sequential I/O. The primary modes include writethrough, writeback, and writearound, with additional behaviors for read prefetching and sequential detection. In writethrough mode, writes are performed synchronously to both the cache and the backing device, ensuring that data reaches stable storage before the operation completes. This approach prioritizes , as there is no risk of loss from uncommitted cache contents. Reads are served from the cache if the data is present (a hit), otherwise fetched from the backing device and potentially cached for future access. If a write to the cache fails, bcache invalidates the corresponding entry in the cache to maintain consistency. This mode is the default when writeback caching is disabled. Writeback mode buffers writes initially in the cache, deferring the transfer to the backing device until later via asynchronous flushes. Dirty data—changes pending write to the backing device—is managed sequentially by scanning the index from start to end, allowing efficient background updates. Reads follow the standard : served from the cache on a hit or from the backing device on a miss, with the missed data loaded into the cache. While this mode offers potential for higher write throughput, it introduces a risk of if the cache device fails before dirty data is flushed to the backing device. Writeback is disabled by default and can be toggled at runtime. The writearound policy bypasses the cache entirely for writes, directing them straight to the backing device to avoid unnecessary SSD wear from patterns that do not benefit from caching, such as large sequential transfers. Reads in this mode are still handled via the cache if applicable, but writes do not populate or modify cache contents. Bcache automatically detects sequential I/O patterns—using a rolling of I/O sizes per task—and applies writearound behavior when exceeding a configurable cutoff (defaulting to 4 MB), skipping caching to prioritize workloads. This detection operates across all cache modes to protect the cache device. For read optimization, bcache supports a read-around mechanism, also known as readahead, which optionally prefetches adjacent blocks into the cache upon a read miss. On a cache miss, the system rounds up the read request to a specified size (default 0, meaning disabled) and loads the additional data from the backing device into the cache, anticipating patterns. This helps improve future hit rates for streaming or sequential reads without affecting write operations.

Performance Enhancements

Bcache achieves high through its efficient structure for metadata management, enabling up to 1,000,000 on random reads when paired with sufficiently fast hardware. The design minimizes lookup overhead by using large nodes that reduce tree depth, while low-overhead metadata operations ensure quick access to cached extents without excessive CPU or I/O costs. This optimization is particularly beneficial for workloads dominated by patterns, where traditional hard disk drives (HDDs) struggle, allowing bcache to accelerate throughput significantly by serving requests directly from the SSD cache. To reduce on solid-state drives (SSDs), bcache employs sequential bucket writes, allocating data in erase block-sized units and filling them contiguously before issuing discards for reuse. Delayed flushes further minimize unnecessary erases by batching dirty data and writing it sequentially to the backing device, scanning the index from start to end. Additionally, bcache avoids caching sequential I/O by default—using a rolling with a 4 MB cutoff—to prevent cache pollution from large, streaming transfers that do not benefit from SSD acceleration, thereby preserving space for random workloads. Bcache supports multiple backing devices per cache set but only a single cache device, with plans for multi-cache support in . Backing devices can also be attached or detached at runtime without or unmounting, using commands like echo <CSET-UUID> > /sys/block/bcache0/bcache/attach, which facilitates dynamic reconfiguration in production environments. This flexibility ensures continuous operation while scaling performance as hardware needs evolve. For error handling, bcache automatically degrades the cache upon detecting excessive I/O errors from the caching device, switching affected backing devices to passthrough mode to bypass the faulty cache and maintain data availability. It retries reads from the backing device on cache read failures and flushes dirty data before shutdown to prevent loss. In 2025, a fix addressed a potential issue in cache flushing to enhance stability (CVE-2025-38263). Options for scrubbing, such as manual garbage collection via trigger_gc, allow detection and invalidation of corrupted cache entries, enhancing reliability over time.

Configuration and Management

Setup Procedures

Setting up bcache involves preparing the kernel environment, formatting the backing and caching devices with superblocks, registering the devices, attaching the cache to the backing device, and then creating a filesystem on the resulting bcache device. Prerequisites include a Linux kernel version 3.10 or later, compiled with the bcache module enabled (CONFIG_BCACHE=y or as a loadable module via modprobe bcache). Additionally, the bcache-tools package must be installed to provide user-space utilities for device registration, available from the official kernel git repository or distribution packages. The backing device is typically a slower HDD (e.g., /dev/sda), while the caching device is a faster SSD (e.g., /dev/nvme0n1); both must be unused (whole disks or partitions) to avoid data loss during formatting. To format and prepare the backing device, run the command bcache make -B /dev/sda, which creates a bcache superblock. With modern bcache-tools, rules may register the device automatically, making it available as /dev/bcache0 (or the next available index). Without automatic registration, manually register it with echo /dev/sda > /sys/fs/bcache/register. This step initializes the device for caching but does not yet enable caching functionality. For the caching device, execute bcache make -C /dev/nvme0n1 to format it and create its superblock. Similarly, register it if needed: echo /dev/nvme0n1 > /sys/fs/bcache/register. The command outputs the cache set UUID, which is required for attachment and can be viewed later in /sys/fs/bcache//. Attach the cache to the backing device by writing the cache set UUID to the attach file: echo <cache-set-uuid> > /sys/block/bcache0/bcache/attach. This links the devices, activates caching on /dev/bcache0, and makes the combined device available for use; the superblock on the backing device stores metadata about the attachment. By default, the cache mode is writethrough and can be adjusted later via sysfs. Finally, create a filesystem on the bcache device, such as mkfs.[ext4](/page/Ext4) /dev/bcache0, and mount it (e.g., mount /dev/bcache0 /mnt) to begin using the cached storage.

Tools and Commands

Bcache management relies on a combination of user-space utilities from the bcache-tools package and the kernel's interface for post-setup operations such as , configuration, and monitoring. The bcache-tools provide command-line utilities for examining bcache structures without altering runtime behavior. For instance, bcache-super-show displays the superblock contents of a cache or backing device, including metadata like UUIDs and bucket sizes, which aids in or verification; the -f option forces continuation even if the superblock is invalid. Another utility, bcache-status, offers a formatted overview of bcache devices, including cache usage, hit rates, and recent performance metrics over intervals like the last five minutes, hour, or day. The primary interface for runtime management is , accessible under /sys/block/bcache<N>/bcache/ for individual bcache devices and /sys/fs/bcache/<cset-uuid>/ for cache sets. Key files include cache_mode, which can be adjusted to modes such as writeback for full caching, writethrough for synchronous writes, or writearound for sequential bypass; changes take effect immediately via commands like echo writeback > /sys/block/bcache0/bcache/cache_mode. The sequential_cutoff parameter sets the threshold for treating I/O as sequential, defaulting to 4 MiB, and can be tuned with echo 0 > /sys/block/bcache0/bcache/sequential_cutoff to disable write-around for all writes. Monitoring is facilitated through statistics directories, such as /sys/block/bcache0/bcache/stats_total/, which track metrics including cache hits, misses, bypassed I/O, and dirty percentages; these counters reveal sizes and cache efficiency without additional tools. For safe detachment during maintenance, echo 1 > /sys/block/bcache0/bcache/stop initiates a graceful shutdown, flushing dirty if in writeback mode before unregistering. Runtime modifications and teardown use sysfs echo commands for detachment and unregistration. To detach a specific cache set, echo <cset-uuid> > /sys/block/bcache0/bcache/detach removes the association while preserving . Full unregistration, which closes cache devices and detaches all backing devices after flushing dirty data, is achieved with echo 1 > /sys/fs/bcache/<cset-uuid>/unregister. These operations support dynamic adjustments post-setup, such as switching cache modes or monitoring without rebooting.

Limitations and Alternatives

Known Issues

One significant risk associated with bcache's writeback caching mode is the potential for during power failures or SSD cache device failures before dirty data is fully flushed to the backing device. In such scenarios, uncommitted writes in the cache may be lost, leading to filesystem inconsistencies or stale data being returned to applications if the cache becomes unavailable. To mitigate this in production environments, it is recommended to pair bcache with an (UPS) for reliable shutdowns or configure the backing device using for added durability. Bcache lacks native support for redundancy mechanisms such as integration or data checksumming, placing the full burden of data durability on the underlying backing device. Without built-in checksumming for user data—limited only to metadata—bcache cannot detect or repair silent in cached blocks, relying instead on the filesystem or storage layer below for checks. This design choice simplifies the block layer cache but exposes users to higher risks in failure-prone setups without additional safeguards like external arrays. Compatibility challenges arise when integrating bcache with certain storage stacks, including potential issues with Logical Volume Manager (LVM) configurations where volume resizing or snapshots may disrupt cache alignment. Similarly, while bcache functions with encrypted devices via , performance degradation or boot-time complications can occur if encryption is layered beneath the cache rather than above it. Bcache is generally unsuitable for use with due to conflicts at the block layer, where ZFS's direct I/O and CoW semantics interfere with bcache's caching operations, often resulting in minor data corruptions or detection failures. Maintenance of bcache requires manual intervention for optimal performance under heavy workloads, particularly in tuning garbage collection to manage cache fragmentation and free space. Administrators must monitor and trigger garbage collection via interfaces like /sys/fs/bcache/<cset-uuid>/trigger_gc to prevent cache exhaustion, as automatic thresholds may not suffice for high-I/O scenarios. Bcache remains actively maintained in the as of 2025, with recent fixes for issues such as a dereference in cache flushing (CVE-2025-38263, fixed in July 2025). The removal of the related filesystem from the mainline kernel—marked as externally maintained in version 6.17 (September 28, 2025) and fully removed in version 6.18 (December 2025)—means advanced filesystem features developed in bcachefs, such as native multi-device redundancy and enhanced checksumming, are not available in the standalone bcache caching subsystem.

Comparisons with Other Solutions

Bcache, as a block-layer caching mechanism in the , differs from LVM's dm-cache in its native integration and simplicity for hybrid SSD/HDD setups. While bcache operates directly at the block device level without requiring additional volume management layers, dm-cache is built on the Device Mapper framework and leverages LVM for configuration, enabling features like online volume conversion and but introducing greater setup complexity through commands such as lvcreate and lvconvert. This makes bcache preferable for straightforward caching of entire block devices in new installations, whereas dm-cache suits environments already using LVM for advanced storage management like striping or . In performance tests using random reads, bcache has demonstrated consistent in optimized configurations, such as up to 68.8k total IOPS, compared to dm-cache's initial peaks around 92k IOPS when the cache is empty but dropping significantly to around 1.5k IOPS under load when full. In contrast to the now-removed , bcache functions solely as a pure caching layer atop existing filesystems and block devices, avoiding the complexities of a full (CoW) filesystem. , which integrated caching with multi-device support, RAID-like redundancy, compression, and checksumming, was marked as externally maintained in the mainline kernel in version 6.17 (September 28, 2025) due to ongoing stability issues and maintainer disputes, with full removal in version 6.18 (December 2025), rendering it unsuitable for production use in mainline kernels. As a result, bcache offers greater long-term stability for caching scenarios post-2025, particularly where users seek to enhance performance without overhauling their filesystem stack. Compared to ZFS's L2ARC, bcache provides block-level caching independent of any specific filesystem, supporting both read and write operations across arbitrary block devices, but it lacks the adaptive, ARC-extending intelligence of L2ARC that prioritizes hot data based on access patterns within pools. L2ARC serves as a secondary read cache on SSDs to offload from RAM-based ARC, excelling in dataset-heavy environments with features like compression and snapshots, yet it requires committing to the full ecosystem, including its licensing and resource demands. Benchmarks indicate L2ARC can double transaction rates in database workloads over bcache by caching more data effectively, though bcache's generality allows its use with filesystems like or without ZFS overhead. Bcache is particularly suited for generic block device caching in SSD/HDD hybrid arrays, where it accelerates random I/O for general-purpose storage, but alternatives like dm-writeboost target specialized write buffering with log-structured designs that minimize overhead for bursty workloads. Dm-writeboost, derived from Solaris's Disk Caching Disk, focuses on efficient reduction through sequential logging on SSDs before flushing to slower backing stores, achieving lower latency in high-write scenarios compared to bcache's broader read/write balancing. Thus, while bcache supports versatile caching modes like writeback for sustained performance gains, dm-writeboost is ideal for applications with unpredictable write patterns, such as or virtual machines, without the full caching overhead of bcache.

References

  1. https://docs.kernel.org/admin-guide/bcache.html
  2. https://bcache.evilpiepirate.org/
  3. https://lwn.net/Articles/394672/
  4. https://lwn.net/Articles/497024/
  5. https://kernelnewbies.org/Linux_3.10
  6. https://kernelnewbies.org/Linux_3.13
  7. https://www.phoronix.com/news/MD-Block-Changes-Linux-4.15
  8. https://www.phoronix.com/news/Bcachefs-Merged-Linux-6.7
  9. https://www.phoronix.com/news/Bcachefs-Removed-Linux-6.18
  10. https://www.suse.com/security/cve/CVE-2025-38263.html
  11. https://bcache.evilpiepirate.org
  12. https://www.kernel.org/doc/html/v6.9/admin-guide/abi-testing.html
  13. https://nvd.nist.gov/vuln/detail/CVE-2025-38263
  14. https://git.kernel.org/pub/scm/linux/kernel/git/colyli/bcache-tools.git/
  15. https://manpages.debian.org/unstable/bcache-tools/bcache-super-show.8.en.html
  16. https://www.mankier.com/8/bcache-status
  17. https://www.kernel.org/doc/Documentation/bcache.txt
  18. https://support.scc.suse.com/s/kb/Potential-for-data-corruption-caused-by-bcache-returning-stale-data-in-writeback-mode-1583239436216
  19. https://bcache.evilpiepirate.org/BcacheGuide/
  20. https://github.com/zfsonlinux/zfs/issues/8340
  21. https://lwn.net/Articles/1040120/
  22. https://storageapis.wordpress.com/2015/03/20/bcache-and-vs-lvm-cache/
  23. https://strugglers.net/~andy/mothballed-blog/2017/07/19/bcache-and-lvmcache/
  24. https://info.varnish-software.com/blog/accelerating-your-hdd-dm-cache-or-bcache
  25. https://lwn.net/Articles/1035736/
  26. https://wiki.archlinux.org/title/Bcache
  27. https://forum.openmediavault.org/index.php?thread/41891-l2arc-cache-zfs-plugin-on-omv/
  28. https://www.percona.com/blog/mysql-zfs-in-the-cloud-leveraging-ephemeral-storage/
  29. https://github.com/akiradeveloper/dm-writeboost
  30. https://lkml.org/lkml/2013/9/1/55
  31. https://documentation.suse.com/sles/15-SP7/html/SLES-all/cha-multitiercache.html
Add your contribution
Related Hubs
User Avatar
No comments yet.