LSM-trees underpin most modern write-optimized databases: RocksDB, LevelDB, Cassandra's storage engine. Writes go to an in-memory buffer, then flush to sorted files on disk. Over time, files accumulate and must be compacted — merged and re-sorted — to maintain read performance. Compaction is the janitor that keeps the database functional.
The janitor has gotten slow relative to the building. NVMe SSDs now deliver millions of IOPS, but compaction still routes every I/O through system calls: open, read, write, fsync. Each system call crosses the user-kernel boundary, and at NVMe speeds, that boundary crossing dominates the actual I/O time. The storage device is faster than the software stack that talks to it.
Yi et al. (arXiv:2603.05162) move compaction into the kernel using eBPF and io_uring. RESYSTANCE reduces system call invocations during compaction by 99%. Not a typo: from thousands of system calls per compaction operation to essentially none. The compaction logic runs as eBPF programs inside the kernel, submitting I/O through io_uring's submission queues without ever crossing back to user space.
The results: 50% reduction in compaction time, up to 75% throughput improvement under write-heavy loads, 40% reduction in p99 latency. The improvement is largest in the tail — exactly where compaction spikes create the most damage to service-level objectives.
Crucially, RESYSTANCE doesn't modify the LSM-tree structure or the compaction algorithm. It changes where the same algorithm runs. The compaction strategy that was optimal in user space is still optimal; it was just being taxed by the boundary crossing. Removing the tax reveals the algorithm's actual performance.
The deeper observation: the kernel-user boundary was designed when I/O was slow and compute was the bottleneck. Now I/O is fast and the boundary itself is the bottleneck. The solution isn't to remove the boundary — it serves security and stability functions — but to move the work to the side of the boundary where the I/O lives.