JuiceFS v1.4.1: Is ~23× object I/O amplification expected for small random reads and overwrites?

[njutli]

Hi, we are testing JuiceFS v1.4.1 with TiKV and Ceph RADOS, using 256 KiB blocks and 50/50 random reads and overwrites, with local caching and writeback disabled.

Application reads and writes are each limited to about 8 MiB/s, but object GET and PUT traffic each reaches about 189 MiB/s—roughly 23× amplification, before Ceph’s internal overhead.

A smaller test also reproduces this: initialize a 64 MiB file as one slice, overwrite 256 KiB at offsets 16 MiB and 48 MiB, then remount and read just 256 KiB. This triggers a 64 MiB compaction, producing 64.5 MiB of GETs and 64 MiB of PUTs.

Is this an expected compaction trade-off? Are there recommended settings or usage patterns to reduce amplification for this workload?

Test methods and results. Thanks for any guidance!

[myangitzh]

Thanks for the detailed report and minimal reproduction. Your analysis is consistent with the current implementation: small overwrites can fragment a large slice enough for a subsequent read to trigger compaction, rewriting the full 64 MiB range.

We recognize that this strategy can cause excessive I/O amplification for workloads like yours. Related improvements are tracked in [#5008], and we plan to optimize the compaction strategy to better balance read performance and compaction cost. Your reproduction provides a useful test case for evaluating those changes.

[njutli]

Thank you for reviewing the report and clarifying the current behavior. We appreciate your efforts to improve the compaction strategy and will keep an eye on #5008 and related updates. Thanks again for your time and help.