APFS is slow for agentic dev, use XFS + VDO
- YT :: https://www.youtube.com/watch?v=4wVNFaFDIn8
- Original title :: Your Mac is slowing you down (a rant about file systems)
Theo benchmarks file systems for agent-heavy development - lots of git worktrees, lots of node_modules, lots of small files - and concludes that macOS APFS is by far the worst option. His recommendation, taken from Wendell (Level1Techs) and then verified with his own benchmarks, is XFS on top of a VDO compression layer using LZ4. The move cut his disk usage roughly in half and made worktree creation nearly instantaneous.
The symptom
A cached pnpm install across a monorepo of framework boilerplates takes ~35 s on his MacBook and under 10 s on a mid-range Linux box. The git clean that deletes those node_modules takes 31 s on an M1 Max versus 6 s on ext4. No network is involved - it is pure local file copying and linking. A Linux box throttled to 550 MHz reached comparable install speed to an M1 Max, which is how badly APFS handles this workload.
What a file system has to be good at for agents
- Speed :: deletion (cleanup), cloning (worktrees), indexing and lookup, and above all handling many small files.
- Features :: copy-on-write so a worktree clone points at existing blocks until you edit, plus useful metadata.
- Support :: kernel inclusion, cross-OS readability (exFAT remains the only broadly portable format).
- Compression :: both space savings and its effect on read/write performance. LZ4 is cheap enough that reads and writes stay fast.
Apple gets credit for the HFS+ to APFS migration - every iPhone converted in place during a point release with no data loss - but its current tradeoffs do not match developer workloads.
Candidates
ext4 is simple, minimal and fast at all file sizes, but has little metadata and no copy-on-write, so every directory and copy is real data. XFS is more extensible and can sit on a VDO compression layer. ZFS and btrfs are aimed at RAID and were ruled out.
Numbers
- Creating one T3 Code worktree: APFS 1.26 s, btrfs ~0.7 s, ext4 0.63 s, XFS similar, ZFS ~0.8 s.
- Creating eight worktrees in parallel: APFS 7.1 s (almost no parallel speedup), ext4/XFS about 5% slower than the single case, btrfs 2.1 s, ZFS over 1 s.
- Clean worktree size: APFS ~240 MB, ext4/XFS ~250 MB, btrfs ~14 MB, XFS+VDO ~128 MB, ZFS ~20 MB.
- After install, XFS+VDO still occupies less than a clean APFS worktree.
- 125 worktrees each with
pnpm install: ext4 75 GB, APFS 43 GB, XFS+VDO 24 GB. - Hard-linked installs expose APFS worst: install time goes from ~40 s to ~100 s, because link creation carries huge overhead on macOS. This matches problems Jarred Sumner hit optimizing
bun install. - Switching his Linux box to XFS+VDO saved 44% of storage; plain XFS saved 10%.
- Real-world worktree creation in T3 Code: 10-12 s down to under 2 s.
The one place plain XFS lagged ext4 - delete and recreate - disappears once pnpm uses hard links (7 s to 2.85 s).
Practical upshot
All his agentic dev work now runs on a Linux box on a separate XFS+VDO drive; over a terabyte of data compressed down to ~360 GB of real blocks. He argues every developer leaning on AI tooling should keep an old machine running Linux with a file system like this and drive agents on it remotely.
For people staying on macOS, he mentions Rift by Anomaly, which virtualizes worktree files with copy-on-write so clones are instant on macOS (and now works on Linux with btrfs) - but its last commit was two months ago, so the project may be dead.