基准测试方法

BrewFS 将性能视为特定负载和 profile下的结果，而不是文件系统的普适排名。每个公开结果都应说明后端、缓存状态、挂载行为、负载形态、主机、软件版本和完整 runner 命令。

当前 Redis + RustFS 参考环境

公开的 2026 年 7 月 24 日对比快照让两个文件系统运行在同一台主机上：

BrewFS Redis 使用 commit_before_upload、2 GiB 读/写内存缓存、8 GiB 持久读缓存、 4 GiB SSD 写回缓存、6 个写回上传 worker、S3 并发 8、上传并发 16。JuiceFS 使用 writeback=true、4 GiB buffer、8 GiB 持久缓存、cache-large-write、4 个上传连接与 4 个 stage-write 线程。读结果基于持久预填充与保留本地缓存的重新挂载；写结果同时报告 应用可见的 tool-wall 吞吐，以及队列归零后的完整排空吞吐。

代表性 Redis 结果

在 14 项应用可见数据结果与 10 项元数据结果中，BrewFS 领先 24 项匹配结果里的 15 项 （数据面 10/14，元数据 5/10）。稳定持久缓存 Large read 基本持平。JuiceFS 仍在顺序读、 严格排空纯写，以及 TiKV create/open/rename 上领先。

完整排空吞吐按 fio 实际字节数除以 active I/O 时间与 post-write drain 之和计算，避免 更大的未排空队列反而抬高写入成绩。本快照不发布几何平均汇总。

这些数值只适用于所列的配置和负载，不能预测冷缓存、超出缓存大小的数据集、远程网络或不同调优方式下的表现。

复现 profile

# BrewFS 对比 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 对比 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 runner 会在 docker/compose-xfstests/artifacts/ 下写入原始报告和日志。发布结果时应保留这些产物，使每条性能结论都可追溯到输入和输出。

公平比较规则

1. 分开报告冷缓存和热缓存；微秒级读可能只是缓存命中，而不是对象存储读取。
2. 明确负载形态、数据集、后端、主机、挂载选项、压缩与 runtime 设置。
3. 标注所有语义取舍。commit-before-upload、只读 direct I/O 与 write-open cache 都是 opt-in profile，不是默认保证。
4. 目标负载至少运行三次，并报告中位数。
5. 非目标 fio 与元数据项目的回退保持在 5% 预算以内。
6. 只要热路径改动可能影响文件系统行为，就重新运行 POSIX 套件；见 POSIX 测试。

如何解读结果

不要把结果直接归因于 Rust。缓存热度、dirty overlay、元数据往返、批处理和 FUSE runtime 都是被测变量。只有这些变量被记录、对齐和允许证伪时，性能数据才有解释力。