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,883 times a second on Blacksmith 2 vCPU and 1,520 on RunsOn m8a.xlarge · EBS gp3, 53× apart; p99 latency is 17 µs against 922 µs.
• Synced 4k writes on x64 run from 498 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,089,234 QD1 reads and 423,214 synced writes per second: 90× and 32× the best local NVMe at 2 vCPU (i7i.large, $0.0010) and 601× and 782× default EBS gp3 (c8a.large, $0.0010); its workspace is 23 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,492 and 1,838 QD1 reads and 498 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 26,620 times a second on Warpbuild xfast (Apple M4 Pro) 6 vCPU and 1,492 on RunsOn c8g.large · EBS gp3, 18× apart; p99 latency is 79 µs against 954 µ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,517 QD1 reads and 7,522 synced writes per second, m8i.2xlarge on EBS gp3 1,571 and 498.
• Same Xeon 6975P-C CPU, different disk: m8id.large on local NVMe answers 11,093 QD1 reads and 5,539 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,046 QD1 reads and 7,973 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,514 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,439 QD1 reads and 14,852 synced writes per second, m9g.xlarge on EBS gp3 1,560 and 542.
• Same Neoverse-V3 CPU, different disk: m9gd.large on local NVMe answers 13,477 QD1 reads and 7,267 synced writes per second, m9g.large on EBS gp3 1,788 and 542.
• 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,815 → 1,773 IOPS): it buys bandwidth, not latency.
• tmpfs on m8a.2xlarge is not a disk at all: 1,153,230 QD1 reads and 427,176 synced writes per second, from RAM. The workspace is 46 GiB, sized by memory.
• tmpfs on m9g.2xlarge is not a disk at all: 664,023 QD1 reads and 301,114 synced writes per second, from RAM. The workspace is 46 GiB, sized by memory.
• tmpfs on m9g.xlarge is not a disk at all: 700,578 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 428,713 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,083,980 QD1 reads and 431,907 synced writes per second, from RAM. The workspace is 46 GiB, sized by memory.
• tmpfs on r9g.large is not a disk at all: 641,530 QD1 reads and 298,044 synced writes per second, from RAM. The workspace is 23 GiB, sized by memory.
• tmpfs on r9g.xlarge is not a disk at all: 658,442 QD1 reads and 302,438 synced writes per second, from RAM. The workspace is 46 GiB, sized by memory.
• tmpfs: 642k–1.2M QD1 reads and 298k–432k synced writes per second across 8 runners (8 RunsOn configurations).
• VM disk: 6.4k–81k QD1 reads and 1.3k–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: 11k–14k QD1 reads and 5.5k–18k synced writes per second across 9 runners (9 RunsOn configurations).
• network disk: 7.5k–8.2k QD1 reads and 4.4k synced writes per second across 2 runners (2 GitHub runners).
• EBS: 1.5k–1.8k QD1 reads and 498–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 51× the QD1 reads of RunsOn m8a.xlarge · EBS gp3 (78,187 against 1,520 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.