When you might want something else
Archil is a network file system, so the cache-miss path always includes a network round-trip. A few cases where a different tool is a better fit:- You need microsecond latency on every operation regardless of working set size. Use local NVMe.
- You already operate a Lustre cluster with HPC tooling and storage admins. Stay on Lustre.
- Your application speaks S3 natively and doesn’t need POSIX or shared access across servers. Just use S3.
How Archil compares to other solutions
The sections below explain how Archil differs from each of the common alternatives in more detail.Block storage (e.g. EBS or Hyperdisk)
Block volumes such as EBS or Hyperdisk attach to one server at a time, are provisioned and billed by size in advance, and don’t synchronize with object storage, so each server keeps its own copy of any data it pulls from S3. An Archil disk is a shared, persistent file system that keeps data in S3 in its native format, and it gives you capabilities a block volume doesn’t:- Sharing across servers: mount the same disk from many servers at once.
- An S3 API: read and write the same files over S3 from anywhere.
- Serverless execution: run commands against the disk without starting a server.
- Elastic capacity: the disk grows and shrinks with your data, so there’s nothing to provision, resize, or pay for while it sits empty.
- Branches and checkpoints: fork a disk or roll it back to an earlier state.
renameat2 flags.
Native FUSE adapters (e.g. S3FS and Mountpoint)
Existing FUSE adapters, such as S3FS and Mountpoint for Amazon S3, are not designed to support full POSIX semantics. For example, Mountpoint for Amazon S3 does not support file locks, random writes, renames, or symbolic links. In order to use these tools, you need to instrument your file applications to understand whether or not they use these unsupported operations, which can be difficult and error-prone. In addition, these tools do not provide shared caching for reference data sets to multiple clients, so large clusters may need to re-download the same data from S3 repeatedly. In comparison, Archil is designed to support all standard POSIX file operations, which means that it’s out-of-the-box compatible with all file applications.Block FUSE adapters (e.g. JuiceFS and ObjectiveFS)
Other disk adapters for S3, such as JuiceFS, ObjectiveFS, or ZeroFS, require that you store data in your S3 bucket in a proprietary block format. This means that you cannot use your existing data sets in S3 with these tools, and these buckets aren’t compatible with any existing S3 workflows that you use. Archil stores data in S3 in its native format, so you can simultaneously use and share the data from both a disk and S3. You can also use Archil to connect to existing data sets in S3.NFS file storage (e.g. Amazon EFS and Amazon S3 Files)
NFS-based file systems, such as Amazon EFS and the newer Amazon S3 Files, are serverless and can be mounted from many servers at once, but the NFS protocol introduces two fundamental limitations that make them unsuitable for many workloads. The first limitation is metadata latency. NFS clients cannot cache the result of mutating metadata operations, so every file creation, rename, or attribute change must round-trip to the server before it can be acknowledged. As a result, metadata-heavy workloads such as source trees, package installs, container image extracts, and most interactive applications are typically an order of magnitude slower on NFS than on a local disk. Archil’s custom file protocol allows clients to take exclusive write access to portions of the file system, so creates and writes can be acknowledged locally without a server round-trip. The second limitation is per-client throughput. NFS clients resolve DNS once at mount time and send every subsequent request to a single IP address, which caps a single client at roughly 3 GiB/s regardless of how much network bandwidth the underlying instance has. This is well below the NIC capacity of large GPU instances, making NFS a bottleneck for model training and other high-throughput workloads. Archil’s protocol allows a single client to talk directly to multiple storage servers in parallel, similar to how parallel file systems like Lustre achieve scale-out throughput, so a single client can saturate the NIC of even the largest GPU instances. Archil also stores data in S3 in its native object format, so the same data is accessible through both the file system and the underlying S3 bucket without any proprietary on-disk layout.Benchmark against Amazon EFS
Each result is the median of 3 runs from the same host. See the methodology below.
Amazon EFS was faster for the single large SQLite insert, sequential writes, and 4 KiB random writes.
To tune Archil for your own workload, see Performance tips or email
support@archil.com.
Benchmark methodology
- Host: AWS c7gn.2xlarge (Graviton3, 8 vCPU, 15 GiB), us-east-1, Amazon Linux 2023. Both file systems were in the same region and tested from the same host on 2026-10-15.
- Archil: a new Archil disk with no data source, mounted with Archil client v0.9.2 and default mount options.
- Amazon EFS: a new file system with General Purpose performance mode, Elastic throughput and Standard storage, mounted with amazon-efs-utils 3.0.1 (TLS, NFSv4.1, rsize/wsize 1 MiB). Amazon S3 Files is built on the same service.
- No network fetches: git clones came from local bare mirrors, and npm used
npm ci --prefer-offlinewith a prefilled cache. Only the file system under test was measured. - Timing: times are wall-clock time until the command returns.
- fio: fio 3.32, buffered I/O, 4 GiB file. 4 KiB random I/O used libaio, iodepth 16, 4 jobs. Cold reads were taken
after unmount,
drop_cachesand remount. - Tool versions: git 2.50.1, Node 24.18.0 / npm 11.16.0, SQLite 3.40.0.
Sandbox platforms (e.g. E2B, Daytona, and Vercel Sandbox)
Archil is a sandbox platform too. Archil sandboxes are Firecracker microVMs with pause and resume, fork, ports, and an egress firewall, and their root filesystem is an Archil disk.Sandbox provider volumes (e.g. Daytona Volumes)
Volumes from a sandbox provider keep files beyond one sandbox, but only within that provider. An Archil disk mounts in Archil sandboxes and over FUSE in sandboxes from any provider that supports it, including Daytona, E2B, and Modal VM sandboxes, and your app can read and write it through the S3 API or the SDKs without starting a sandbox.Shared file storage (e.g. Alluxio and FSx for Lustre)
Some solutions, like Alluxio or FSx for Lustre, require that you either deploy and manage your own infrastructure or that you provision capacity. It’s often difficult to predict the specific storage needs of an application, especially if the application can have unexpected or bursty needs. Archil is a fully managed, serverless solution that automatically scales with your application. You don’t need to provision capacity or deploy infrastructure. Metered usage counts toward your paid plan’s monthly minimum.See the pricing page for plans and usage rates.