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 107,149 times a second on Namespace 8x16 and 1,430 on RunsOn m8a.2xlarge · EBS gp3, 75× apart; p99 latency is 10 µs against 995 µs.
• Synced 4k writes on x64 run from 487 per second on RunsOn m8i.2xlarge · EBS gp3 (workspace mounted nobarrier) to 30,012 on Namespace 4x8.
• r8a.large with tmpfs ($0.0009/min at spot) answers 1,107,000 QD1 reads and 428,125 synced writes per second: 90× and 33× the best local NVMe at 2 vCPU (i7i.large, $0.0010) and 612× and 791× default EBS gp3 (c8a.large, $0.0009); its workspace is 14 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 32,691 times a second on Blacksmith 4 vCPU and 1,777 on Warpbuild 2 vCPU, 18× apart; p99 latency is 37 µs against 840 µs.
• Synced 4k writes on arm64 run from 537 per second on RunsOn c8g.large · EBS gp3 (workspace mounted nobarrier) to 17,416 on RunsOn m9gd.2xlarge · local NVMe.
• Same Xeon 6975P-C CPU, different disk: m8id.2xlarge on local NVMe answers 10,966 QD1 reads and 7,472 synced writes per second, m8i.2xlarge on EBS gp3 1,580 and 487.
• Same Xeon 6975P-C CPU, different disk: m8id.large on local NVMe answers 11,102 QD1 reads and 5,555 synced writes per second, m8i-flex.large on EBS gp3 1,767 and 528.
• Same Xeon 6975P-C CPU, different disk: m8id.xlarge on local NVMe answers 10,878 QD1 reads and 7,930 synced writes per second, m8i-flex.xlarge on EBS gp3 1,751 and 524.
• Same Neoverse-V3 CPU, different disk: m9gd.2xlarge on local NVMe answers 13,446 QD1 reads and 17,416 synced writes per second, m9g.2xlarge on EBS gp3 1,812 and 543.
• Same Neoverse-V3 CPU, different disk: m9gd.xlarge on local NVMe answers 13,382 QD1 reads and 14,861 synced writes per second, m9g.xlarge on EBS gp3 1,822 and 543.
• Same Neoverse-V3 CPU, different disk: m9gd.large on local NVMe answers 13,533 QD1 reads and 7,267 synced writes per second, m9g.large on EBS gp3 1,789 and 542.
• Provisioning gp3 at 1000 MiB/s on m8a.2xlarge takes sequential reads from 401 MiB/s to 1,001 MiB/s (2.5×); QD1 reads go (1,587 → 1,776 IOPS).
• 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,648 → 1,771 IOPS): it buys bandwidth, not latency.
• tmpfs on m8a.2xlarge is not a disk at all: 1,135,113 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,126 QD1 reads and 300,362 synced writes per second, from RAM. The workspace is 29 GiB, sized by memory.
• tmpfs on m9g.xlarge is not a disk at all: 669,005 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,153,982 QD1 reads and 430,608 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,102,306 QD1 reads and 433,841 synced writes per second, from RAM. The workspace is 29 GiB, sized by memory.
• tmpfs on r9g.large is not a disk at all: 651,023 QD1 reads and 297,673 synced writes per second, from RAM. The workspace is 14 GiB, sized by memory.
• tmpfs on r9g.xlarge is not a disk at all: 642,690 QD1 reads and 302,278 synced writes per second, from RAM. The workspace is 29 GiB, sized by memory.
• tmpfs: 643k–1.2M QD1 reads and 298k–434k synced writes per second across 8 runners (8 RunsOn configurations).
• VM disk: 5.3k–107k QD1 reads and 806–30k synced writes per second across 44 runners from 7 providers (6 Avrea runners, 6 Blacksmith runners, 3 boat x64 runners, 3 GitHub runners, 12 Namespace runners, 9 Ubicloud runners and 5 Warpbuild runners).
• local NVMe: 11k–14k QD1 reads and 5.6k–17k synced writes per second across 9 runners (9 RunsOn configurations).
• network disk: 5.9k–7.3k QD1 reads and 2.9k–4.2k synced writes per second across 2 runners (2 GitHub runners).
• EBS: 1.4k–1.8k QD1 reads and 487–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.

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.