A compressed filesystem must solve two objectives that pull in opposite directions. Large compression windows expose more repeated byte sequences, while small independent blocks let the system fetch and decompress only the requested region. RubikFS, presented at FAST 2026 by Harbin Institute of Technology, Shenzhen and Huawei Technologies, argues that block size is not the only control. A read-only image can rearrange its contents once, before deployment, so that similar and frequently accessed chunks land in blocks that serve both objectives[1].
This is a placement result rather than a new codec. RubikFS retains fixed-size, page-aligned compressed blocks and works with LZ4, Zstandard, and LZMA. It changes the image builder that decides which chunks share those blocks. Across six open-source embedded and container images, the paper reports as much as a 42.60% improvement in compression ratio over EROFS and Squashfs configurations. In a separate hot-data experiment, grouping the frequently read chunks cuts unnecessary reads by as much as 70.70% and runtime by as much as 65.03%. Those maxima come from different compressors and traces, so they define a range of observed effects rather than one combined speedup.
Block boundaries mix data that compression wants together
EROFS and Squashfs divide an image into independently compressed units. This provides bounded access: reading one file does not require expanding the entire image. However, the division follows filesystem layout rather than byte-level similarity. Executable code, data sections, scripts, and binary assets may share a block even when their repeating patterns live elsewhere. A dictionary cannot exploit a match that falls outside its current window.
Simply increasing the block from 4 KB toward 1 MB does not close the gap with compressing the image as one stream. It also makes a small read pull in more unrelated bytes. The paper names this tension data mixture. The useful system question is therefore not only how large a compression block should be, but which data should occupy it.
Read-only images create an unusual opportunity. IoT firmware, board images, and container layers are built ahead of use and are not modified in place. Their physical order can change as long as the filesystem index maps logical offsets to the new locations. RubikFS spends additional work during image construction to improve every later deployment. That bargain is reasonable for an image distributed to many devices, but it does not transfer directly to a write-heavy filesystem where every update could invalidate the arrangement.
Four stages turn image construction into a placement pipeline
The builder begins with a data grouper. It separates broad content types before the expensive similarity calculation, reducing comparisons that are unlikely to be useful. Executable code and executable data are treated separately, and the structured sections inside binaries provide a stronger first partition than ordinary file order. This pre-grouping also reduces mistaken matches between byte patterns that happen to resemble one another but serve different access behavior.
A data chunker then breaks files into content-defined units and removes exact duplicates. Chunk size adapts to file size, which prevents tiny files from producing excessive metadata while preserving enough granularity in larger files. The index overhead reported by the paper ranges from 0.018% to 2.93%, depending on the chosen chunk size. Deduplication captures identical content, but it cannot find partial redundancy among chunks that differ.
The similarity sorter addresses that remaining redundancy. It samples chunk content into compact features, constructs a graph whose edges represent similarity, and partitions the graph into groups small enough to process. Chunks within a group are ordered so that related byte sequences fall inside the compressor’s available dictionary. The authors use a sampling rate of 1/128 and subgraphs of 64 chunks by default. Their sensitivity tests show less than 0.03× compression-ratio difference among subgraph sizes of 32, 64, and 128, which suggests that the result does not depend on one narrow parameter.
Lastly, a hotness grouper reserves locality for data expected to be read together. Similarity alone could scatter popular pages among cold blocks and make each request decompress irrelevant data. RubikFS first gathers hot chunks and then applies similarity ordering within the resulting constraints. This is the step that turns an offline density optimization into a runtime filesystem design.
The evaluation separates image building from image reading
Image construction ran on a server with 32 CPU cores and 128 GiB of DRAM. Runtime experiments used FEMU, a QEMU-based NVMe SSD emulator configured with 4 KB pages and 75 microseconds of page-read latency. The emulated embedded host had two CPU cores, 1 GiB of DRAM, and Linux 6.16. FEMU makes the I/O conditions reproducible, but the results are not measurements from multiple commercial flash devices.
The six inputs span a 42 MB OpenHarmony image through a 771 MB Friendica container image. The set also includes openEuler, two larger OpenHarmony board images, and a Yocto root filesystem. RubikFS is compared with EROFS, Squashfs, and a direct whole-image compression reference across block sizes from 4 KB to 1 MB. LZ4, Zstandard, and LZMA are all tested at their highest configured compression levels.
RubikFS consistently improves compression ratio over the two block-compressed filesystems and sometimes exceeds the whole-image reference. Sorting can place repeated sequences next to each other even when their original physical distance is larger than the codec dictionary. This matters most for LZ4, whose evaluated dictionary is capped at 64 KB. A larger filesystem block alone cannot extend that dictionary, while rearrangement can bring a useful match inside it.
The comparison requires care because the systems define block size differently. Squashfs specifies it before compression, whereas EROFS and RubikFS target a size after compression. The direct baseline also gives up independent filesystem blocks. It is a compression ceiling, not a deployable substitute with equivalent random-access behavior.
Hotness protects runtime from the density optimization
The paper constructs two openEuler traces in which 12% or 40% of the data is hot. The 12% case corresponds to the authors’ stated deployment experience of roughly 10% to 15%; the 40% case is a stress condition. With a 1 MB block, RubikFS reads less data and finishes sooner than the evaluated EROFS and Squashfs variants for all three codecs.
Under the 12% trace, LZ4 RubikFS reads 16.41 MB and completes in 1.21 seconds. The corresponding EROFS result reads 56.00 MB and takes 2.89 seconds. LZMA compresses more effectively and reads only 10.13 MB, yet its decompression cost raises runtime to 3.72 seconds. This comparison shows why the smallest stored image is not automatically the fastest image.
At 40% hot data, LZ4 completes in 3.02 seconds, Zstandard in 3.03 seconds, and LZMA in 6.34 seconds. The hotness constraint changes compression ratio by less than 0.11× even in that extreme case. Thus, the placement policy preserves most density while avoiding the worst read amplification. A buyer still needs to choose the codec from the device CPU and startup deadline, not from compression ratio alone.
Offline cost is paid once but must still be budgeted
Graph construction and partitioning add image-build work. RubikFS reduces it by grouping content types before similarity analysis. Against a sorter without the data grouper, the paper reports construction-time reductions from 21.97% to 74.39%. The absolute effect varies sharply: similarity sorting adds hundreds of seconds on some larger OpenHarmony images, while a small 42 MB image can build faster because better ordering also shortens compression.
This cost model favors centrally built, widely replicated artifacts. A firmware vendor can spend minutes once and distribute the result to millions of devices. A container pipeline that rebuilds layers for every commit has a different denominator. It should count builder CPU time, cacheability of unchanged layers, and the delay introduced into release promotion.
The implementation also assumes that hotness is known before the image is sealed. Stable boot paths and embedded appliances can provide that profile. General containers may change behavior across services or versions. If the declared hot set is wrong, correctness is unaffected, but runtime locality can regress toward ordinary block compression.
Deployment should compare bytes read and CPU time together
RubikFS changes the decision from selecting a codec in isolation to co-designing image layout, codec, and access profile. The first deployment metric should be physical bytes read per useful page. The second should be decompression CPU time on the actual device. Image size, startup latency, and builder time complete the comparison.
The strongest candidates are immutable images with repeated structured content, a stable hot set, and large deployment multiplicity. The weakest are writable data, encrypted or already compressed assets with little similarity, and workloads whose hot pages cannot be predicted. The paper evaluates images up to 771 MB and discusses scaling the sorter by grouping and graph partitioning, but it does not establish behavior for multi-gigabyte, continuously rebuilt container estates.
An adoption test should retain EROFS or Squashfs with the same codec and block target, then add sorting without changing the decompressor. That isolates placement value. It should also report cold-start tail latency rather than only average read time, since a few badly grouped boot-critical pages can dominate device readiness. When storage capacity is the primary constraint, compression ratio matters; when startup is the constraint, bytes read and codec latency decide whether that density is useful.
RubikFS shows that a filesystem image is not merely an ordered list of files. For immutable deployments, it is a compiled layout. The compiler can use content similarity and expected access as inputs, just as a code compiler uses control flow and cache locality. The practical limit is equally clear: the more the runtime differs from the build-time profile, the less valuable that compilation becomes.
Source and copyright notice
This article is an independent editorial digest of the publicly available FAST 2026 paper. The mechanisms, measurements, and limitations were restated in new language after checking the official USENIX paper page. No sentence, table, or publisher figure is reproduced. The explanatory figure and thumbnail were created for this article from the reported system structure and data. Copyright © 2026 the authors.