ARCHIL

A buyer’s guide

Storage for agents

An agent’s work lives in files: the repository it cloned, the packages it installed, the database it wrote to, the notes it left for the next run. Where you keep those files decides whether the work survives a lost machine, how long every step takes, whether a second agent can pick it up, and what you pay while it sits idle.

I spent eight years on the Amazon EFS team before we started Archil, and almost every conversation I have about storage for agents comes down to the same seven questions. Each question has a chapter that answers it for a buyer in a few minutes, with our measurements and a test you can run yourself.

For the mechanisms underneath, from fsync() to copy-on-write, see the companion guide, How file systems work. If you read only this page, read the seven questions and the checklist at the end.

Hunter LeathFounder & CEO, Archil

Checked against vendor docs, November 2026The whole guide as Markdown

One agent’s workspace on an Archil disk outlives the machine it started on. A second machine mounts the disk and finds every file, and a 33 ms branch gives the next attempt its own copy.

The seven questions

  1. 01

    Is it really a file system?

    Git, npm, SQLite, and most agent tools assume that renames are atomic, files can be edited in place, and directories can be listed. Storage that only resembles a file system breaks them in ways that show up late.

    If you get it wrong
    Tools fail late and in odd ways: a rename that isn’t atomic, a symlink that can’t be created, a database that can’t write in place.
    How to check
    Run a script that renames over an existing file, overwrites bytes in the middle of a file, creates a symlink and a hard link, and sets the executable bit.

    Chapter 1 →

  2. 02

    When is a write safe?

    Sandboxes are moved and retired without notice. A write is safe only if it was replicated to other machines before fsync returned.

    If you get it wrong
    After a host is lost, files that your program had already synced are missing or out of date.
    How to check
    Time 4 KiB writes with fdatasync using fio. A median well under a millisecond means the acknowledgment came from the machine you’re on.

    Chapter 2 →

  3. 03

    How fast is it on small files?

    Clones, installs, and SQLite commits are thousands of small files. Their speed depends on round trips per file, not on throughput.

    If you get it wrong
    git clone and npm install take a minute or more on storage that benchmarks well on throughput.
    How to check
    Time npm ci on a real project, and stop the clock when the writes are durable, not when the command returns.

    Chapter 3 →

  4. 04

    Can many machines use it at once?

    Parallel agents, a reviewer beside a writer, and a sandbox that picks up where another stopped all need the same files on more than one machine, with rules for who writes.

    If you get it wrong
    A second agent reads a stale file, or two agents overwrite each other’s changes without an error.
    How to check
    Write a file on one machine and read it on another. Measure how long the change takes to appear, and what happens when both write.

    Chapter 4 →

  5. 05

    Can you fork it?

    Agents try things. A copy-on-write fork gives every attempt its own workspace in milliseconds, and you throw the bad ones away.

    If you get it wrong
    Each new attempt waits minutes for a copy, so the harness runs fewer attempts and checkpoints less often.
    How to check
    Fork a 1 GiB workspace and your largest one. If the times differ, the fork is a copy.

    Chapter 5 →

  6. 06

    What does it cost when nothing is running?

    Most agent workspaces sit idle most of the time. Storage that’s billed by provisioned size, or that’s tied to a running machine, charges you for the waiting.

    If you get it wrong
    The storage bill stays flat when the agents stop working, or the files disappear along with the sandbox.
    How to check
    Price one workspace for a month in which an agent uses it for an hour a day.

    Chapter 6 →

  7. 07

    Where does your data live?

    If the files end up as ordinary objects in your own bucket, every other tool can read them and leaving is a copy, not a migration.

    If you get it wrong
    Leaving the vendor means a migration, and other tools can read the files only through the vendor.
    How to check
    Write a file, then look in the bucket: is it there, at its path, as an ordinary object?

    Chapter 7 →

The scorecard

Each kind of storage answers the seven questions the same way, whoever sells it, because the answers follow from how it’s built. So the following scorecard rates architectures, not products. The products built each way are listed under each heading. For more information about each product, see the product comparisons.

How each kind of storage answers the seven questions. Each cell gives a rating, Yes, Partly or No, and a short reason.
QuestionLocal diskA sandbox’s own disk, EC2 instance storeLocal disk, uploaded laterVercel Drives, Fly.io SpritesNetwork block volumeAmazon EBS, Google Persistent DiskNFSAmazon EFS, Amazon S3 Files, Google FilestoreMetadata databaseJuiceFSObject storage over FUSEMountpoint for Amazon S3, s3fs, Cloud Storage FUSEArchilArchil disks
01A real file systemYes: All of POSIX, on one machineYes: All of POSIX on the machine; one writerYes: All of POSIX; one machine at a timeYes: All of POSIX; close-to-open between machinesYes: A POSIX file system, by its own descriptionNo: No in-place edits; renames copied or refusedYes: All but ACLs and some rename flags
02Writes survive a lost machineNo: Survives a reboot, not a lost hostNo: Lost until the upload finishesYes: Replicated within one zone before acknowledgingYes: Stored by the server first; One Zone is single-zonePartly: Kept by default; write-back mode uploads laterYes: Kept once fsync uploads the objectYes: Replicated across zones before fsync returns
03Fast on small filesYes: FastestYes: Local speed, before the uploadYes: Close to localNo: A round trip per callNo: A database round trip per callNo: An object request per callYes: Within seconds of local disk on installs; slower when clients contend for one path
04Many machines at onceNo: One machineNo: One writer; others get stale snapshotsNo: One machine at a time; hand off by detachingPartly: Many writers, close-to-open; the last write wins silentlyPartly: Close-to-open; the last write to each byte staysPartly: Fast visibility; no in-place edits or locksPartly: Many writers, at remote speed or at local speed on checked-out paths; new files appear elsewhere in about 30 s unless the reader refreshes
05Instant forksPartly: Instant snapshots with btrfs, on that machine onlyPartly: Vendor snapshots and forks, which can miss recent writesPartly: Snapshots restore as a new volume, loaded lazilyNo: No native branching on EFSPartly: juicefs clone per file or directory, not atomicPartly: Bucket forks on Tigris; none on S3Yes: 13 ms checkpoints, 33 ms branches, on managed disks; branches can’t be deleted yet
06Cheap while idleNo: Kept only while you pay for the machinePartly: A stored copy or the running machine, by vendorNo: Full provisioned size, every hour; can’t shrinkPartly: Bytes stored, at file-storage ratesPartly: Object-storage rates, plus an always-on databaseYes: Object-storage rates; nothing has to runYes: Active rate only near use; archive or bucket rate otherwise
07Data in your bucketNo: On one machineNo: The vendor’s storage, in its accountNo: A disk image; snapshots S3 tools can’t readPartly: Readable only over a mount on EFS; S3 Files writes ordinary objects after 60 s without writesPartly: Your bucket, but as numbered blocks readable only through JuiceFSYes: Ordinary objects, for what it can writePartly: Managed disks, the default, use our format, read through our S3 API or a mount; bucket-synced disks leave ordinary objects, without modes or links
Yes Partly, or it depends on the product No

Questions to ask any vendor

Each of the following questions has a precise answer: a number, a mechanism, or a test you can run. A vague answer is an answer too.

  1. 01Is rename() atomic over an existing file? Can a program overwrite bytes in the middle of a file without rewriting all of it?A real file system
  2. 02Which POSIX features don’t you support: hard links, symbolic links, permissions, or extended attributes?A real file system
  3. 03When fsync() returns, how many machines hold the data, and are they different from the one my code runs on?Writes survive a lost machine
  4. 04If the host dies a millisecond after fsync() returns, what does the next reader see?Writes survive a lost machine
  5. 05How many network round trips does it take to create, write, and close one small file?Fast on small files
  6. 06When one machine writes a file, how long until another machine reads the new contents? What happens when both write?Many machines at once
  7. 07How long does a fork take at 1 GiB, and at the size of my largest workspace?Instant forks
  8. 08Am I billed for each fork’s full size, or only for what it changes?Instant forks
  9. 09What do I pay for a workspace that nobody has touched for a week?Cheap while idle
  10. 10Where are my files stored, in what format, and how do I get all of them out?Data in your bucket

Local disk is the right answer for a single machine that never shares its files. Amazon EFS is faster than Archil when one client writes one large file. In our tests, EFS wrote a 4 GiB file at 590 MB/s and Archil at 194 MB/s, and we have more work to do on throughput. This guide is about the common case for agents: many small files, many machines, and work worth keeping. If you’re going to pay a network round trip to reach your storage, you should get something in return.