An append-only store turns random updates into sequential writes. Old versions become garbage inside immutable log files. Conventional collection selects a file, copies its valid records elsewhere, and deletes the original. More aggressive collection consumes less capacity but rewrites more valid data, so space amplification and write amplification move in opposite directions.
ByteDance’s storage hierarchy magnifies the trade. An upper service maps logical files into ByteStore segments and chunks, while the underlying filesystem and SSD each allocate at their own granularity. Copying valid bytes consumes network, CPU, disk bandwidth, and flash endurance. Leaving garbage consumes provisioned capacity. A production policy must minimize their total cost without adding tail latency to foreground I/O.
DisCoGC introduces discard as a second reclaim path. If a stale logical range is large and suitably aligned, the system marks its underlying space unused without relocating neighboring live data. Compaction remains available for small or fragmented garbage. The design contribution is not the existence of trim; it is the coordination needed to make range reclamation reliable across several allocation layers.
A discard crosses several incompatible boundaries
The BlockServer discovers invalid ranges while scanning its log metadata. It sends an asynchronous discard through ByteStore to the underlying filesystem, which punches a hole or deallocates extents. The SSD can then receive trim for corresponding logical block addresses and avoid moving their stale physical pages during device garbage collection.
Each layer rounds requests differently. A range aligned to a LogFile can straddle an erasure-code stripe, a chunk cluster, filesystem extent, or SSD unit. The paper’s example loses more than half of reclaimable space at combined boundaries. Issuing many small requests also updates metadata repeatedly, and an SSD may support trim at only a small fraction of its write IOPS.
DisCoGC extends a new discard range slightly into an adjacent range already discarded. The overlap is safe because discard is reentrant for stale space, and it lets a later operation recover garbage previously trapped at a boundary. Erasure-code layout is adjusted so a discarded unit covers complete stripes and does not leave partial clusters allocated.
Batching and flow control protect foreground service
A single discard may cover several ranges in one LogFile, allowing the underlying store to update its allocation metadata once. In factor analysis, a batch size of 64 increased the fraction of discardable bytes actually processed to nearly one and reduced logical write amplification by another 2.7% to 11.7% beyond the initial discard path.
Parallelism and IOPS limits prevent a scan or write burst from flooding the lower layer. Tasks with the largest reclaimable ranges receive priority, while flow control caps trim demand. When discard falls behind, garbage accumulates, raises a LogFile’s garbage ratio, and eventually makes that file eligible for compaction. The fallback preserves progress instead of treating discard as the only collector.
The system persists issued and completed discard ranges in a write-ahead LogFile. After a crash it reconstructs ranges that were issued but not confirmed and retries them. Reentrancy makes retry safe. Bitmap compression records failures or differences rather than every successful unit; the reported optimization reduced bitmap size by 25% to 45%.
Foreground isolation is a configured objective rather than an accidental result. Operators select maximum batch size, concurrent requests, and discard IOPS so worst-case CPU increase remains below 2%. In the reported tuning, average CPU overhead was 1.2% and typical batch size was about ten. A burst can reach thresholds and spill into compaction, bounding resource use.
Production traces identify the workloads that fit
ByteDance characterized online, sequential append-and-rewrite (SAR), and offline traces. In the online trace, 4 KiB requests accounted for over 60% of writes, whereas requests above 256 KiB accounted for just 12%. SAR had 65% above 256KiB and only 15% at 4KiB. Large sequential overwrites create contiguous invalid regions that discard can reclaim efficiently; random updates scatter garbage into small pieces.
In the mixed production workload, more than 90% of invalid ranges exceeded 128KiB and more than 70% exceeded 1MiB. That distribution explains the reported outcome. DisCoGC reduced logical write amplification by 32% while space amplification moved from 1.37 to 1.23, a 10% reduction. SSD-internal physical write amplification rose by as much as 10% in some conditions, but combined write amplification fell 25%.
The authors estimate a 20% total-cost reduction for the production clusters. Per-TiB bandwidth and average and p99 latency remained effectively unchanged in the monitoring interval. TCO is a model derived from capacity and write costs, not an invoice that every operator will reproduce. Hardware price, replication, energy, SSD endurance, and reserve capacity can change the weights.
Trace replay shifted every workload’s space-versus-logical-write curve toward the lower left. SAR produced an estimated TCO reduction above 25%. The fragmented online trace benefited least; in fallback to compaction-only behavior, the authors still estimate 2% to 5% savings. They explicitly advise against the implementation effort for a purely random fragmented workload.
Discard can improve host writes while worsening device writes
Logical write amplification counts bytes rewritten by the distributed store. Physical write amplification counts NAND work caused inside the SSD. Discard reduces future live-data copying at the host, but holes fragment the logical address space and can make device garbage collection more frequent. In the paper’s measurements, that effect raised physical amplification by 2% to 10% depending on configuration.
Trim then counteracts part of the device cost by telling the flash translation layer which pages are dead. On one evaluated PCIe SSD, enabling trim reduced physical amplification from 1.4 to 1.3, but added 600 microseconds to chunk-delete latency. The delete path was not the foreground bottleneck. Another model had different trim limits, demonstrating that host policy cannot assume uniform firmware behavior.
The trim filter drops ranges too small to justify device overhead, and a merger combines adjacent logical ranges. The threshold is tuned so trim IOPS remains below 85% of the device maximum. Filtering alone can leave more stale pages and increase physical writes; merging can recover request efficiency without sending every fragment.
This cross-layer sign reversal is the paper’s most important warning. A dashboard that reports only logical writes can declare success while NAND wear rises. A rollout needs host read and write bytes, allocated capacity, filesystem discard completion, SSD trim IOPS, device physical amplification, and endurance consumption on the same timeline.
The mechanism changes the collector’s decision boundary
Compaction and discard are complementary. Discard is cheap for large continuous garbage but loses efficiency at boundaries and under request limits. Compaction handles fragments and also consolidates live data, but pays for copying. DisCoGC uses frequent lightweight discard to lower ordinary pressure and schedules compaction when residual garbage crosses a threshold.
Factor analysis quantifies each part. Adding discard and flow control reduced logical amplification by 8.4% to 13.9%. Batching contributed another 2.7% to 11.7%. Boundary extension then reduced it by an additional 5.5% to 16.1%. Foreground bandwidth and latency stayed stable in those trace configurations. The increments are not independent universal constants; they depend on range distribution and allocation geometry.
Operators should first histogram invalid ranges and map every allocation unit from logical file through erasure coding, chunk storage, filesystem, and SSD. If most reclaimable bytes sit in large ranges, a discard path is credible. If most sit below the minimum useful range, optimizing compaction or changing write placement may be more valuable.
Crash testing must interrupt each point between range discovery, write-ahead logging, lower-layer deallocation, and completion recording. Capacity accounting must not expose discarded space for reuse before the authoritative layer confirms it. Encryption and erasure coding also need to ensure that a partial discard cannot make still-live data unrecoverable.
TCO falls only when saved copying outweighs coordination
DisCoGC demonstrates that an old block command becomes a cloud-storage primitive when range ownership, crash recovery, batching, and device limits are explicit. Its 20% production TCO estimate rests on a favorable mixed workload with mostly large invalid ranges. The design retains compaction because no discard policy can make fragmented garbage contiguous after the fact.
The procurement decision is therefore not “does the SSD support trim?” It is whether the complete stack can expose invalid ranges large enough to reclaim, drive the command below firmware limits, and measure both logical and physical consequences. ByteDance’s result shows that this coordination can reduce total writes by 25% without a latency penalty, while its trace analysis shows exactly when the same engineering would not pay back.
Source and copyright notice
This article is an editorial analysis by Silicon & Systems. It restates the production design, measurements, and limitations in our own words. No source sentence, table, or figure is reproduced; the figure was created for this article. The paper is available from the USENIX FAST 2026 presentation page. Copyright remains with the authors, 2026.