Fastest GitHub Actions runners: disk I/O.

How this shows up in real builds →

What the numbers say

Extremes on x64, and RAM against disk.

• On x64, one small read at a time (4k, QD1) comes back 80,310 times a second on Namespace 8x32 and 1,543 on RunsOn m8i.2xlarge · EBS gp3, 52× apart; p99 latency is 12 µs against 971 µs.
• Synced 4k writes on x64 run from 489 per second on RunsOn m8i.2xlarge · EBS gp3 (workspace mounted nobarrier) to 18,654 on Blacksmith 2 vCPU (workspace mounted nobarrier).
• r8a.large with tmpfs ($0.0010/min at spot) answers 1,105,119 QD1 reads and 426,617 synced writes per second: 91× and 32× the best local NVMe at 2 vCPU (i7i.large, $0.0011) and 619× and 789× default EBS gp3 (c8a.large, $0.0008); its workspace is 14 GiB, from RAM. (EC2 storage suite) What that does to real builds.

More findings23: EBS, arm64, NVMe vs EBS, provisioned gp3, tmpfs, storage classes

• Every EBS-backed workspace (3 AWS CodeBuild x64 runners, 25 RunsOn configurations and 3 Warpbuild configurations) answers between 1,543 and 1,837 QD1 reads and 489 to 571 synced writes per second, whoever runs it and whatever throughput it is provisioned for: each request is a round trip to network storage.
• On arm64, one small read at a time (4k, QD1) comes back 27,941 times a second on Warpbuild xfast (Apple M4 Pro) 6 vCPU and 1,642 on RunsOn m9g.xlarge · EBS gp3, 17× apart; p99 latency is 56 µs against 1,004 µs.
• Synced 4k writes on arm64 run from 537 per second on RunsOn c8g.large · EBS gp3 (workspace mounted nobarrier) to 17,569 on RunsOn m9gd.2xlarge · local NVMe.
• Same Xeon 6975P-C CPU, different disk: m8id.2xlarge on local NVMe answers 10,286 QD1 reads and 7,106 synced writes per second, m8i.2xlarge on EBS gp3 1,543 and 489.
• Same Xeon 6975P-C CPU, different disk: m8id.large on local NVMe answers 11,182 QD1 reads and 5,542 synced writes per second, m8i-flex.large on EBS gp3 1,745 and 532.
• Same Xeon 6975P-C CPU, different disk: m8id.xlarge on local NVMe answers 10,996 QD1 reads and 8,057 synced writes per second, m8i-flex.xlarge on EBS gp3 1,740 and 520.
• Same Neoverse-V3 CPU, different disk: m9gd.2xlarge on local NVMe answers 13,508 QD1 reads and 17,569 synced writes per second, m9g.2xlarge on EBS gp3 1,810 and 543.
• Same Neoverse-V3 CPU, different disk: m9gd.xlarge on local NVMe answers 13,455 QD1 reads and 14,869 synced writes per second, m9g.xlarge on EBS gp3 1,642 and 543.
• Same Neoverse-V3 CPU, different disk: m9gd.large on local NVMe answers 13,480 QD1 reads and 7,267 synced writes per second, m9g.large on EBS gp3 1,789 and 543.
• Provisioning gp3 at 1000 MiB/s on m8a.2xlarge takes sequential reads from 402 MiB/s to 1,002 MiB/s (2.5×); QD1 reads barely move (1,791 → 1,792 IOPS): it buys bandwidth, not latency.
• Provisioning gp3 at 1000 MiB/s on m8azn.xlarge takes sequential reads from 401 MiB/s to 1,001 MiB/s (2.5×); QD1 reads barely move (1,780 → 1,757 IOPS): it buys bandwidth, not latency.
• tmpfs on m8a.2xlarge is not a disk at all: 1,111,843 QD1 reads and 428,937 synced writes per second, from RAM. The workspace is 29 GiB, sized by memory.
• tmpfs on m9g.2xlarge is not a disk at all: 653,094 QD1 reads and 299,229 synced writes per second, from RAM. The workspace is 29 GiB, sized by memory.
• tmpfs on m9g.xlarge is not a disk at all: 677,120 QD1 reads and 304,088 synced writes per second, from RAM. The workspace is 14 GiB, sized by memory.
• tmpfs on r8a.2xlarge is not a disk at all: 1,150,238 QD1 reads and 428,713 synced writes per second, from RAM. The workspace is 59 GiB, sized by memory.
• tmpfs on r8a.xlarge is not a disk at all: 1,150,953 QD1 reads and 432,796 synced writes per second, from RAM. The workspace is 29 GiB, sized by memory.
• tmpfs on r9g.large is not a disk at all: 634,536 QD1 reads and 296,835 synced writes per second, from RAM. The workspace is 14 GiB, sized by memory.
• tmpfs on r9g.xlarge is not a disk at all: 644,236 QD1 reads and 302,278 synced writes per second, from RAM. The workspace is 29 GiB, sized by memory.
• tmpfs: 635k–1.2M QD1 reads and 297k–433k synced writes per second across 8 runners (8 RunsOn configurations).
• VM disk: 5.5k–80k QD1 reads and 976–19k synced writes per second across 43 runners from 7 providers (6 Avrea runners, 6 Blacksmith runners, 3 GitHub runners, 12 Namespace runners, 2 StarSling x64 runners, 9 Ubicloud runners and 5 Warpbuild runners).
• local NVMe: 10k–14k QD1 reads and 5.5k–18k synced writes per second across 9 runners (9 RunsOn configurations).
• network disk: 7.2k–7.9k QD1 reads and 4.1k–4.3k synced writes per second across 2 runners (2 GitHub runners).
• EBS: 1.5k–1.8k QD1 reads and 489–571 synced writes per second across 31 runners from 3 providers (3 AWS CodeBuild x64 runners, 25 RunsOn configurations and 3 Warpbuild configurations).

Reading these numbers

fio measures what a disk can do. Whether a job gets there depends on the job.

At 4 vCPU, Namespace 4x8 answers 44× the QD1 reads of RunsOn m8a.xlarge · EBS gp3 (78,187 against 1,771 per second), and the Rust build takes 1m 52s on one and 1m 48s on the other. Every build, per runner.

What each column says about a job

• QD1 reads and synced writes: databases, SQLite-backed tests and anything that flushes each write. Every flush waits for the storage, and a network disk pays a round trip each time.
• Random writes at depth and sequential throughput: docker build layers, package installs and cache archives. They batch their writes and run into the disk's ceiling, not its latency.
• None of them: compile jobs. A compiler waits for the CPU, and it reads its files back from the page cache.

Every runner

Each provider's best disk first; its other machines sit behind +N more. Bars are log scale.

Pick the disk per job on RunsOn

• The instance type sets the storage under the workspace: EBS gp3 by default, provisioned gp3 for bandwidth, local NVMe on the d and i families, or tmpfs when the job fits in RAM. Pick it with the family label; each one, measured: EC2 storage benchmark.
• What tmpfs does to real builds, what it costs and where it does nothing: Disks? Where we're going, we don't need disks.

How it's measured

Methodology →

fio runs inside the job, in GITHUB_WORKSPACE: the disk a build writes to, on the filesystem the provider mounted there. Every runner is compared, whatever its shape.

fio settingsblock sizes, queue depths, mounts

• QD1 random read: 4k blocks, one request in flight; IOPS and p99 latency.
• Sync write: 4k writes, each followed by fdatasync.
• Random read and write: 4k blocks, 4 jobs with 32 requests in flight each.
• Sequential read and write: 1M blocks, 32 requests in flight.
• The workspace filesystem, its size and its mount options come from the job's own mount table.
• Earlier versions of this page used a different harness and other fio settings on 2 vCPU runners; those numbers are gone rather than mixed in.