Benchmark Methodology

BrewFS reports performance as a property of a specific workload and profile, not as a universal filesystem ranking. Every published result should identify the backend, cache state, mount behavior, workload shape, host, software revision, and the exact runner command.

Current Redis + RustFS reference setup

The published July 24, 2026 comparison snapshot uses the same host for both filesystems:

BrewFS Redis uses commit_before_upload, 2 GiB read and write memory caches, an 8 GiB persistent read cache, a 4 GiB SSD writeback cache, six writeback upload workers, S3 concurrency 8, and upload concurrency 16. JuiceFS uses writeback=true, a 4 GiB buffer, an 8 GiB persistent cache, cache-large-write, four upload connections, and four stage-write threads. Read rows use durable prefill and a cache-preserving remount; writes report both application-visible tool-wall throughput and fully drained throughput after the queue reaches zero.

Representative Redis results

Across 14 application-visible data rows and 10 metadata rows, BrewFS leads 15 of 24 matched rows (10 of 14 data-path, 5 of 10 metadata). Stable persistent-cache Large read is effectively tied. JuiceFS still leads sequential read, strictly drained pure writes, and TiKV create/open/rename.

Fully drained throughput is actual fio bytes divided by active I/O time plus post-write drain, so a larger unflushed queue does not inflate the write result. No geometric-mean summary is published for this snapshot.

These values are useful for the listed configuration and workload only. They do not predict cold-cache, larger-than-cache, remote-network, or differently tuned deployments.

Reproduce the profiles

# BrewFS comparison profile
PERF_LOG_TO_CONSOLE=false PERF_FIO_SIZE=512m PERF_FIO_RUNTIME=20 \
bash docker/compose-xfstests/run_redis_perf.sh --s3 --writeback-throughput-profile

# JuiceFS comparison profile
JUICEFS_META_BACKEND=redis PERF_LOG_TO_CONSOLE=false \
PERF_FIO_SIZE=512m PERF_FIO_RUNTIME=20 \
bash docker/compose-xfstests/run_juicefs_perf.sh --writeback-throughput-profile

Compose runners write raw reports and logs below docker/compose-xfstests/artifacts/. Keep those artifacts with the report so a claim can be traced to its inputs and output.

Fair-comparison rules

1. Report cold and warm cache separately; a microsecond read may be a cache hit, not an object-store read.
2. Keep workload shape, data set, backend, host, mount options, compression, and runtime settings explicit.
3. Name any semantic trade-off. commit-before-upload, read-only direct I/O, and write-open caching are opt-in profiles, not default guarantees.
4. Run the target workload at least three times and report the median.
5. Keep non-target fio and metadata regressions within a 5% budget.
6. Re-run the POSIX suites whenever a hot-path change can affect filesystem behavior; see POSIX Testing.

Interpreting the result

Do not attribute a result to Rust alone. Cache warmth, dirty-overlay behavior, metadata round trips, batching, and FUSE runtime behavior are all measured variables. The performance data is strongest when those variables are recorded, compared, and made falsifiable.