I'd been running into a lot of disk pressure on my system from agents running. I discovered two main causes:
- my approach to using git worktrees for all work. Not entirely surprising, the duplicated build artifacts in each worktree being the main culprit here. There were some limited gains to be had by just being more efficient with how builds were managed but ultimately I just had to limit the number of concurrent features I was working on in a couple of particularly large repos.
- more insidious was the fact I was actually hitting memory limits more than I realised and causing my mac to have to swap heavily. The system was surprisingly still quite performant while this was happening... until it wasn't. Unfortunately as best I can tell the only "fix" when this happens is to restart the machine. There's no way to have the system reclaim any of the swap space once it's written to disk. Which if you have it thrash a couple of times a day (especially easy if you leave something running overnight) adds up very quickly.
It's so goddamn bad, I wish it was easier to turn all of this garbage off. I used to spend time defining parallel work lanes to issue to subagents as frontloaded development work with set validation checkpoints and it worked great. Now attempting to do this with 8, 16 subagents will balloon out into hundreds of gigs of fucking mess
Copy on write worktrees do absolutely nothing to solve this, either. The build artifacts alone will do it
Agreed. I thought I was being smug by telling my agents to use btrfs for specific workloads. Sure, it took me longer to run out of space, but I of course ended up running out of space
I'll take a stab in the dark here and say that if you're using Docker (or Rancher, etc..) I found they aren't releasing memory properly and caused a similar issue to what you're describing.
Switching to Orbstack solved the problem for me because of their memory management efforts. Just wanted to mention it in case it leads to an easy fix for someone else too.
same here — not trying to shill OrbStack, but switching to it has "magically" solved weird problems that would otherwise have consumed my actual time to debug
switching to copy on write worktrees is the biggest game changer it should become common knowledge pretty soon and it's already available on most operating systems
You also need a deduplication, because with simple copy on write you will have a copy for writing the same - change a byte in a file, get a copy, then change it back, get a duplicate.
Deduplication in ZFS needs 5G of RAM for 1TB of logical data - if you expect your agents to produce 2TB of data, you should provide 10G of RAM for deduplication.
Why are your agents expected to produce 2TB of data? Not criticizing, I'm curious. Outside of classifiers I don't have any of my agents produce data, they produce scripts to produce data so it can be deterministic
Any substantial work on substantial software project can give you that. It is often the case with C++ that some logic resides in header files included by most of the project. If you change that logic, you have to rebuild your project and you will get mostly the same object and/or executable files for most of source code, but still slightly different [1].
Tons of screenshots to check for visual bugs - they have a tendency to run smoke tests and benchmarks for everything - and as tokens get cheaper it's easier to fan out more and more subagents that set up their own environment etc. if you want to get the capabilities you're paying for out of them you have to let them run in a loop hill climbing until everything works. But if you don't invest in specifically supporting the agentsby building a good dev environment for them - sure they're good enough to unblock themselves but whatever they do is going to be chock full of slop (like the crashpad reports...). And they won't clean up after themselves. Partly because dumber models and smart models hitting a stupid spike will clean up after themselves by wiping your dev server and breaking all the other sessions that unblocked themselves in chaotic ways, partly because you might have updated permissions/instructions after a previous rather annoying experience like that to strictly ban commands that delete files and containers and stuff. I was running into my machine crashing after hundreds of gigs of storage space were consistently being eaten up over a day and it was all slop. Dead worktrees, "smoke tests," dead docker containers, dead anonymous volumes, files full of screenshots, playwright screen recordings at way too high a resolution, clones of a dev DB, saved logs, etc. a lot of that was fixed by a couple instructions in a markdown file telling the agents to not be stupid about that but a lot of the rest requires actually investing in the agent's dev environment so like they can run their own independent server without doing some ad hoc nonsense that leaves behind yet another random docker volume
thanks to the parent you're replying to, I discovered there's numerous projects that try to retrofit CoW into worktrees + also fill in the gaps for mostly-shared data like build artifacts! I've decided to take lane (https://github.com/lukeed/lane) for a spin as I type to see how it goes.
- my approach to using git worktrees for all work. Not entirely surprising, the duplicated build artifacts in each worktree being the main culprit here. There were some limited gains to be had by just being more efficient with how builds were managed but ultimately I just had to limit the number of concurrent features I was working on in a couple of particularly large repos.
- more insidious was the fact I was actually hitting memory limits more than I realised and causing my mac to have to swap heavily. The system was surprisingly still quite performant while this was happening... until it wasn't. Unfortunately as best I can tell the only "fix" when this happens is to restart the machine. There's no way to have the system reclaim any of the swap space once it's written to disk. Which if you have it thrash a couple of times a day (especially easy if you leave something running overnight) adds up very quickly.