A shared filesystem
for collaborative agents
Agents do not only read files. They continuously read, write, scan, update, and exchange artifacts. BrewFS is optimized for this RandRW-heavy pattern — in the July 24, 2026 Redis + RustFS snapshot it delivers 92% more fully drained mixed-I/O throughput versus JuiceFS under the same matched profile.
Why agent workloads stress filesystems differently
Agents are not sequential readers
Traditional data-processing focuses on sequential throughput. Agent workloads repeatedly perform small reads, partial writes, directory scans, metadata lookups, and artifact updates.
Agents constantly scan project structure
Coding, research, and data agents frequently execute directory traversal, stat, open, read, write, and rename operations.
Agents produce many intermediate files
Plans, logs, patches, tool outputs, reports, caches, indexes, and temporary files all become part of the active workspace.
Agents share state
In multi-agent systems, one agent's output often becomes another agent's input. The filesystem becomes the coordination layer.
More agents amplify random IO
A single agent already creates a complex random read/write pattern. Multiple agents running together amplify random IO, metadata pressure, and concurrent workspace updates.
One shared namespace for collaborative agents
BrewFS lets multiple agents work in the same filesystem namespace. Each agent reads existing context, writes intermediate artifacts, updates task outputs, and hands off results through normal file paths.
This structure is easy for agents to understand, easy for humans to inspect, and easy for infrastructure teams to persist on object storage.
/workspace
├── context/
│ ├── repo-summary.md
│ └── user-requirements.md
├── agents/
│ ├── planner/ plan.md
│ ├── executor/ result.json logs.txt
│ ├── reviewer/ review.md
│ └── reporter/ final.md
├── artifacts/
│ ├── patch.diff
│ ├── benchmark.csv
│ └── output.png
└── memory/
├── task-state.json
└── index-cache.binHow real agents hit the filesystem
Five common agent patterns, each with a distinct IO profile that BrewFS is built to handle.
Coding Agents
Multiple coding agents scan repositories, read source files, generate patches, write test results, and exchange analysis reports through a shared BrewFS workspace.
Typical IO
Mixed random I/O is where agent workloads hurt most
The July 24, 2026 README snapshot compares BrewFS and JuiceFS on the same local host with Redis metadata, RustFS S3-compatible storage, compression disabled, matching writeback profiles, buffered io_uring fio, durable read prefill, and strict post-write drain. BrewFS leads 15 of 24 matched rows. Fully drained mixed I/O is 92% faster; foreground mixed I/O is 51% faster; random read is 37% faster.
Benchmark environment
Application-visible and fully drained throughput
| Workload | BrewFS | JuiceFS | Ratio |
|---|---|---|---|
| Large read | 194.34 MiB/s | 194.17 MiB/s | ~1.00x |
| Sequential read | 740.60 MiB/s | 1,000.76 MiB/s | 0.74x |
| Random read | 1,726.10 MiB/s | 1,256.80 MiB/s | 1.37x |
| Large write (foreground) | 195.05 MiB/s | 102.40 MiB/s | 1.90x |
| Sequential write (foreground) | 189.33 MiB/s | 117.94 MiB/s | 1.61x |
| Random write (foreground) | 178.17 MiB/s | 117.43 MiB/s | 1.52x |
| Mixed random I/O (foreground) | 495.54 MiB/s | 328.76 MiB/s | 1.51x |
| Large write (fully drained) | 66.47 MiB/s | 79.13 MiB/s | 0.84x |
| Sequential write (fully drained) | 88.50 MiB/s | 144.44 MiB/s | 0.61x |
| Random write (fully drained) | 89.31 MiB/s | 138.89 MiB/s | 0.64x |
| Mixed I/O total (fully drained) | 218.60 MiB/s | 113.86 MiB/s | 1.92x |
| Hot local-cache Large read | 2,395.32 MiB/s | 2,356.73 MiB/s | ~1.02x |
Metadata throughput
| Operation | BrewFS | JuiceFS | Ratio |
|---|---|---|---|
| Create | 1,004.61 ops/s | 549.01 ops/s | 1.83x |
| Open | 4,827.50 ops/s | 11,883.85 ops/s | 0.41x |
| Stat | 726,234.51 ops/s | 724,328.73 ops/s | ~1.00x |
| Readdir | 28,634.94 ops/s | 16,020.25 ops/s | 1.79x |
| Rename | 894.64 ops/s | 1,313.40 ops/s | 0.68x |
Write completion accounting
| Workload | BrewFS tool wall / post-drain | JuiceFS tool wall / post-drain |
|---|---|---|
| Large write | 21 s / 41 s | 40 s / 12 s |
| Sequential write | 21 s / 24 s | 70 s / 37 s |
| Random write | 24 s / 24 s | 70 s / 39 s |
| Mixed random I/O | 26 s / 33 s | 21 s / 40 s |
Complete tool wall time
| Tool | BrewFS wall | JuiceFS wall | Result |
|---|---|---|---|
| fio-bigread | 31 s | 5 s | pass / pass |
| fio-bigwrite | 21 s | 40 s | pass / pass |
| fio-seqread | 20 s | 21 s | pass / pass |
| fio-seqwrite | 21 s | 70 s | pass / pass |
| fio-randread | 21 s | 20 s | pass / pass |
| fio-randwrite | 24 s | 70 s | pass / pass |
| fio-randrw | 26 s | 21 s | pass / pass |
| metaperf | 293 s | 194 s | pass / pass |
| dirstress | 1 s | 3 s | pass / pass |
| dirperf | 17 s | 14 s | pass / pass |
Important notes
- Both filesystems use their runner writeback-throughput profile. This is a throughput-oriented comparison, not a durability-equivalence claim.
- Fully drained throughput is actual fio bytes divided by active I/O time plus post-write drain.
- BrewFS leads 15 of 24 matched rows (10/14 data-path, 5/10 metadata). JuiceFS still leads sequential read, strictly drained pure writes, and TiKV create/open/rename.
- This is a local engineering snapshot from July 24, 2026, not a universal performance claim for every deployment.
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_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