XBOF: CXL-Enabled SSD Resource Sharing
- XBOF is a disaggregated SSD design that separates compute and data functions, enabling fine-grained resource sharing via a cache-coherent CXL fabric.
- The design harvests idle ARM processor and DRAM resources from underutilized SSDs to improve overall utilization and reduce monetary costs by 19.0%.
- A decentralized management approach facilitates processor and memory harvesting, achieving a 50.4% boost in SSD resource utilization with minimal latency overhead.
XBOF is a cost-efficient just a bunch of flash (JBOF) design that uses Compute eXpress Link (CXL) to enable inter-SSD compute resource sharing within a storage enclosure. It is motivated by the observation that enterprise SSDs integrate numerous computing resources, such as ARM processors and onboard DRAM, to satisfy the performance requirements of I/O bursts, but that the sporadic nature of those bursts causes severe SSD resource underutilization at JBOF level. XBOF addresses this cost-utilization imbalance by reserving only moderate computing resources in individual SSDs and then harvesting idle processor and DRAM resources from other SSDs through a cache-coherent CXL fabric, thereby improving SSD resource utilization by 50.4% and saving 19.0% monetary costs with a negligible performance loss (Yi et al., 12 Sep 2025).
1. Problem setting and design objective
Modern enterprise SSDs provision substantial embedded compute and memory resources in order to absorb bursty workloads such as cloud storage and ML inference. In a JBOF deployment, tens of such SSDs are clustered to provide high aggregate throughput, but burstiness is not synchronized across devices. The reported consequence is substantial underutilization: in a Tencent JBOF with 25 SSDs, at least 20 are under 75% utilization during 94.6% of uptime, and average drive bandwidth utilization can be as low as 8-28% across providers (Yi et al., 12 Sep 2025).
XBOF is formulated against a specific cost-utilization dilemma. High SSD bill of material (BOM) cost is incurred for embedded processor and DRAM capacity that remains idle most of the time, yet removing those resources outright degrades burst performance. The design target is therefore not maximal per-drive provisioning, but a JBOF-level architecture in which moderate per-SSD resources can be pooled dynamically and used where instantaneous demand appears (Yi et al., 12 Sep 2025).
The paper positions this objective against two classes of alternatives. Open-Channel SSDs (OCSSDs) outsource controller and memory requirements to the host and can save BOM, but negatively impact performance and compatibility. Coarse-grained SSD virtualization and harvesting collect idle SSDs into resource pools, but treat SSDs as monolithic black boxes, causing resource stranding and incurring overhead due to data copyback and centralized management. XBOF is proposed specifically to avoid that coarse granularity (Yi et al., 12 Sep 2025).
2. Disaggregated SSD architecture
The architectural core of XBOF is SSD disaggregation by function. Instead of treating an SSD as a monolithic device, XBOF divides it into two independent components: a compute-end and a data-end (Yi et al., 12 Sep 2025).
| Component | Constituents | Role |
|---|---|---|
| Compute-End | ARM processors, onboard DRAM, DDR controller | Handles firmware tasks such as address translation and command parsing |
| Data-End | Flash backbone, DMA engine, data buffers | Handles physical NAND I/O and data transfer |
| Interconnect | CXL Type-2 controller | Connects the two ends and enables global memory pooling and cache-coherent access |
This disaggregation is the mechanism that makes fine-grained resource management possible. Traditional SSDs tightly couple compute and flash resources behind a block interface. In XBOF, the compute-end can be stressed while the data-end is lightly loaded, or vice versa; once these subsystems are separated, idle compute resources on one SSD can assist a different SSD without requiring whole-device reassignment (Yi et al., 12 Sep 2025).
The design uses the cache-coherent capability of CXL to support this separation. Each SSD exposes part of its DRAM to the JBOF-wide CXL fabric as global coherent memory, referred to as G-FAM. This permits all SSDs and the host to read and write that memory, and enables busy SSDs to directly utilize harvested computing resources to accelerate metadata processing (Yi et al., 12 Sep 2025).
A plausible implication is that XBOF shifts the optimization target from per-device peak self-sufficiency to fabric-level elasticity. That interpretation follows from the explicit disaggregation and from the fact that the shared resources are processor and DRAM rather than flash channels themselves.
3. Decentralized management and resource discovery
XBOF uses a decentralized management scheme rather than a host-centric resource manager. Each SSD maintains an idle resource table in DRAM and advertises idle compute or DRAM resources in units of resource descriptors. The descriptor fields are given as valid, type, assigned borrower, utilization, and addresses (Yi et al., 12 Sep 2025).
Borrowers scan these tables and atomically lock resources for use. Idle lenders update their offered resource descriptors periodically. The operational logic is implemented by an XBOF daemon on each SSD, which monitors utilization, posts and updates resource state, handles lending and borrowing, and bridges remote command execution and data movement between compute-end and data-end (Yi et al., 12 Sep 2025).
This decentralized control is significant because prior systems are described as suffering host bottlenecks, with centralized managers causing up to 21% throughput loss. XBOF instead adopts a multi-device, decentralized, and self-governing approach. The host-side component still participates in load balancing through WRR NVMe queue features, but the control plane for resource advertisement and locking is distributed across the SSDs themselves (Yi et al., 12 Sep 2025).
A common misconception would be to view XBOF as merely a CXL-attached memory pool for SSD metadata. The design is broader than that: it includes both processor harvesting and DRAM harvesting, and it couples these with firmware-level coordination and transparent I/O redirection (Yi et al., 12 Sep 2025).
4. Inter-SSD processor and DRAM harvesting
XBOF defines two resource-harvesting mechanisms.
Processor harvesting addresses cases in which an SSD’s compute-end is stressed but its data-end is not. A compute-light SSD acts as a lender, and a stressed SSD acts as a borrower. The borrower offloads portions of its firmware workload, such as NVMe I/O commands and address translation, by forwarding them through shadow submission queues to a lender. The lender accesses the borrower’s metadata over CXL, processes the command, and interacts with the borrower’s data-end, while data transfer remains local to the borrower to ensure data integrity. The host NVMe driver is slightly modified to handle I/O redirection between SSD pairs for processor harvesting (Yi et al., 12 Sep 2025).
DRAM harvesting operates at segment granularity. Lender SSDs allocate unused DRAM segments, for example 2 MB units, and advertise them to borrowers. Borrowers then cache portions of their mapping tables or metadata in the lender’s DRAM to improve cache hit/miss ratio and reduce flash reads. Unlike coarse-grained harvesting schemes, this is explicitly fine-grained: XBOF shares independent compute or memory segments rather than whole devices (Yi et al., 12 Sep 2025).
Crash consistency is handled with per-segment logging. Modifications to remote-cached metadata generate log records in local DRAM, which are flushed and replayed in the event of device failure. The paper states that this satisfies enterprise requirements such as Power Loss Protection (PLP) (Yi et al., 12 Sep 2025).
These mechanisms are enabled by CXL.mem and CXL.cache. The paper’s evaluated system uses PCIe x2 at 16 GB/s, and the design is presented as compatible with the larger-scale memory fabrics of CXL 3.0, which supports large-scale, multi-level, rack-scale memory fabrics and systems that can scale to thousands of devices (Yi et al., 12 Sep 2025).
5. Implementation and measured behavior
The prototype combines firmware and host modifications. Firmware changes were implemented on a DaisyPlus OpenSSD board with ARM Cortex-A53 and FPGA, and the host side required Linux 5.15 NVMe driver patches of approximately 1 K LOC. Evaluation used SimpleSSD, extended to model XBOF, and was cross-validated with a NUMA-based emulation platform (Yi et al., 12 Sep 2025).
The central quantitative results are summarized below.
| Metric | Result | Comparison basis |
|---|---|---|
| SSD resource utilization | 50.4% higher | Compared to a “Shrunk” resource-limited SSD baseline |
| Monetary cost | 19.0% lower | Compared to existing JBOF designs |
| Lender throughput loss | 1.3% | While borrowers improve by 15-30% |
| Inter-SSD latency overhead | ~20 ns per redirection decision | Additional CXL and inter-SSD communication cost |
The performance claims are deliberately framed around maintaining burst behavior with reduced per-drive resources. With halved internal compute resources, XBOF’s throughput matches that of traditional full-resource JBOFs across realistic workloads. The additional compute and memory indirection is described as negligible because flash operations remain dominant in the latency breakdowns (Yi et al., 12 Sep 2025).
Cost efficiency is also reported at the device level. By allowing each SSD to be built with just half as much processor and DRAM, XBOF cuts device cost by 19% over traditional JBOF SSDs. For a 2 TB SSD, throughput per dollar is improved by nearly 20% over OCSSD and 19% over traditional designs (Yi et al., 12 Sep 2025).
The paper further states that XBOF avoids the additional write-back traffic associated with naive virtualization-based harvesting and therefore preserves SSD lifetimes, in contrast to a reported 22.5% write-endurance reduction in that alternative (Yi et al., 12 Sep 2025).
6. Position within storage-system design
XBOF occupies a specific point in the design space between fully provisioned enterprise SSDs, host-offloaded OCSSDs, and coarse-grained harvesting systems. Its defining characteristic is not disaggregation alone, but disaggregation combined with direct inter-SSD sharing over a cache-coherent CXL fabric and decentralized control (Yi et al., 12 Sep 2025).
Relative to traditional JBOF, XBOF lowers processor and DRAM provisioning per drive while attempting to preserve burst throughput through borrowing. Relative to OCSSD JBOF, it does not move controller functionality wholesale to the host and therefore avoids the compatibility and performance penalties attributed to that approach. Relative to monolithic virtual harvesting, it avoids resource stranding by harvesting compute or memory segments independently rather than collecting entire SSDs into a pool (Yi et al., 12 Sep 2025).
This suggests that XBOF is best understood as a storage-local disaggregated architecture rather than a generic external accelerator framework. The borrowed resources remain inside the JBOF, the flash data path remains tied to the borrower, and the principal acceleration target is metadata processing. That scope is narrower than full storage virtualization but more granular than whole-device pooling.
The paper’s conclusion is correspondingly specific: XBOF is a cost-efficient CXL JBOF with inter-SSD compute resource sharing that improves utilization by 50.4% and reduces monetary cost by 19.0% with negligible performance loss (Yi et al., 12 Sep 2025).
