Anatomy of a remote file system

Earlier this year, I worked on a remote file system for agents. The intention was to enable faster multiplayer collaboration between different agents or clones of the same agent.

The legacy system had relied on moving files between cloud storage and the code sandboxes that our agents were using. However, it had a number of issues that the new design was going to solve:

1. Issue 1 was that code sandboxes were mostly ephemeral, which meant that a fresh sandbox would need to download any files into the sandbox all over again.
2. Issue 2 was that, as the number of files grew, it took longer and longer to boot up the sandbox, as we reached the limits of what concurrent file downloads allowed us to achieve before. It also took longer to shutdown the sandboxes, as we had to wait for new and edited files to finish uploading to cloud storage before we could safely shutdown the sandboxes.
3. Issue 3 was that transient infrastructure issues or sandbox crashes could lead to data loss because the files were not saved yet.
4. Issue 4 was that we had a lot of orchestration logic inside the sandbox startup code that managed the synchronization of files across different code sandboxes. Additionally, the agent needed an extra skill to tell it what files were safe to edit, which were private vs shared, and a number of metadata files to keep track of the synchronization state.

After doing some research into how E2B, Archil, Code.storage and Mesa.dev were approaching this challenge, I came up with our own multiplayer remote file system.

In this series of posts, I want to share the design I came up with and the considerations that were made.

1. Post 1: A minimal remote file system
2. Post 2: Caching and Sparse Materialization
3. Post 3: Automated Conflict Resolution
4. Post 4: Handling infrastructure issues

For this first post, we'll describe a naive implementation with the minimal parts necessary for a remote file system. In later posts, we will discuss the improvements we made.