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 81,150 times a second on Blacksmith 8 vCPU and 1,539 on RunsOn m8i.2xlarge · EBS gp3, 53× apart; p99 latency is 13 µs against 1,057 µ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,097,813 QD1 reads and 424,773 synced writes per second: 91× and 32× the best local NVMe at 2 vCPU (i7i.large, $0.0010) and 606× and 785× default EBS gp3 (c8a.large, $0.0010); its workspace is 23 GiB, from RAM. (EC2 storage suite) What that does to real builds.

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

• On arm64, one small read at a time (4k, QD1) comes back 26,620 times a second on Warpbuild xfast (Apple M4 Pro) 6 vCPU and 1,466 on RunsOn m9g.xlarge · EBS gp3, 18× apart; p99 latency is 79 µs against 1,028 µs.
• Synced 4k writes on arm64 run from 537 per second on RunsOn c8g.large · EBS gp3 (workspace mounted nobarrier) to 17,511 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,361 synced writes per second, m8i.2xlarge on EBS gp3 1,539 and 489.
• Same Xeon 6975P-C CPU, different disk: m8id.large on local NVMe answers 11,124 QD1 reads and 5,540 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 11,059 QD1 reads and 8,128 synced writes per second, m8i-flex.xlarge on EBS gp3 1,707 and 520.
• Same Neoverse-V3 CPU, different disk: m9gd.2xlarge on local NVMe answers 13,508 QD1 reads and 17,511 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,441 QD1 reads and 14,867 synced writes per second, m9g.xlarge on EBS gp3 1,466 and 542.
• Same Neoverse-V3 CPU, different disk: m9gd.large on local NVMe answers 13,466 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 go (1,780 → 1,541 IOPS).
• tmpfs on m8a.2xlarge is not a disk at all: 1,120,738 QD1 reads and 424,611 synced writes per second, from RAM. The workspace is 46 GiB, sized by memory.
• tmpfs on m9g.2xlarge is not a disk at all: 663,906 QD1 reads and 301,046 synced writes per second, from RAM. The workspace is 46 GiB, sized by memory.
• tmpfs on m9g.xlarge is not a disk at all: 682,673 QD1 reads and 303,857 synced writes per second, from RAM. The workspace is 23 GiB, sized by memory.
• tmpfs on r8a.2xlarge is not a disk at all: 1,151,439 QD1 reads and 426,203 synced writes per second, from RAM. The workspace is 92 GiB, sized by memory.
• tmpfs on r8a.xlarge is not a disk at all: 1,120,049 QD1 reads and 432,796 synced writes per second, from RAM. The workspace is 46 GiB, sized by memory.
• tmpfs on r9g.large is not a disk at all: 634,536 QD1 reads and 295,874 synced writes per second, from RAM. The workspace is 23 GiB, sized by memory.
• tmpfs on r9g.xlarge is not a disk at all: 651,339 QD1 reads and 301,773 synced writes per second, from RAM. The workspace is 46 GiB, sized by memory.
• tmpfs: 635k–1.2M QD1 reads and 296k–433k synced writes per second across 8 runners (8 RunsOn configurations).
• VM disk: 6.0k–81k QD1 reads and 1.2k–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: 6.6k–8.2k QD1 reads and 4.3k–4.4k 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 (77,281 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.