Filesystem

Builds on Common Methodology

Measures the rate at which stress-ng creates and removes hard links in /workspace/hardlink.

Package managers such as pnpm install packages by creating thousands of hard links from a global store into the project (node_modules).

Because creating and removing hard links never transfers file data blocks, its speed is governed by the metadata system-call path inside the sandbox: the guest kernel's filesystem and its locking, any overlay filesystem, any layer that intercepts system calls, and single-core CPU speed.

The Filesystem tab measures that metadata rate in /workspace/hardlink using stress-ng's Hard Links stressor.

View the Procedure View Hard Links Results Download Raw Data View the Parameters

Metrics

Hard Links

Hard Links is the rate of hard links created per second in /workspace/hardlink over an elapsed denominator of both link() creation and unlink() removal time, reported by stress-ng's link stressor (links-createdremoved-per-sec in out.yaml).

Hard Links (2 vCPU / 8 GiB)

Hard Links (2 vCPU / 8 GiB) is the same measurement as Hard Links, taken in a 2 vCPU / 8 GiB sandbox.

Timed Part	Starts	Ends
Hard Links	stress-ng's link stressor begins, after the untimed mount facts and the check of the pinned tool; nothing is sent between the check and this command.	stress-ng has run one worker for 30 s, removed its last links and exited; its rate is its own count over its own clock.

R_{\mathrm{links},\,i} = \dfrac{L_{\mathrm{created},\,i}}{T_{\mathrm{stressor},\,i}}

• R_{\mathrm{links},\,i} Hard links per second in trial i.
• L_{\mathrm{created},\,i} Total number of hard links successfully created across all rounds in trial i.
• T_{\mathrm{stressor},\,i} stress-ng's internal elapsed wall-clock time in seconds in trial i (approximately 30 s), which spans both creating the hard links and unlinking them at the end of each round.

In each round, a single stress-ng worker creates up to 8,192 hard links to a seed inode in /workspace/hardlink and then unlinks all of them; at the end of the 30 s run, stress-ng divides the total count of successfully created hard links across all rounds by the total elapsed run time (creation plus removal) to report links-createdremoved-per-sec.

Measurement

Each trial uses a sandbox created from BoxRouter's pinned standard image, running a static Linux x86_64 build of stress-ng V0.19.02 (verified by SHA-256).

1. Create sandbox and run readiness check.
2. Record the backing filesystem and mount options of /workspace/hardlink, verify at least 100 MiB free space, and upload and verify static stress-ng. An untimed setup step runs a 256 MiB shared-memory probe to detect whether /workspace/hardlink is backed by RAM (tmpfs/ramfs).
3. Hard Links Run ./stress-ng (Hard Links). Timed The trial runs ./stress-ng --link 1 --metrics --no-rand-seed -t 30 --temp-path /workspace/hardlink --yaml /workspace/hardlink/out.yaml as a polled background script (guest clock).
4. Parse out.yaml and destroy sandbox. The trial parses links-createdremoved-per-sec and bogo-ops-per-second-real-time from /workspace/hardlink/out.yaml.

Scope Limits and Caveats

• Runs a single-worker system-call loop without calling fsync, so the rate reflects both VFS/syscall overhead and single-core CPU speed in memory rather than physical disk write time.
• The published metric is individual hard links per second (links-createdremoved-per-sec), not bogo ops/s, because one bogo op is a whole round of up to 8,192 links plus their removal.
• Each round creates and unlinks the same 8,192 filenames in /workspace/hardlink, so path lookups benefit from the kernel's directory entry cache after round 1.
• The link stressor silently retries a link() call that fails with EDQUOT, ENOMEM, EMLINK, EINTR or ENOSPC without counting it, and the check for at least 100 MiB of free space prevents ENOSPC in normal operation.
• When /workspace/hardlink is backed by tmpfs or ramfs, or the 256 MiB probe raises shared memory by at least 80% of 256 MiB, the in-memory check attaches a note that no block device sits behind the filesystem.

Failures and Exclusions

Outcome classifications, top-up rounds, and outlier rules follow Common Methodology; the first failed step ends the trial without in-trial retries.

A sandbox with fewer than 100 MiB free in /workspace/hardlink is recorded as a missed trial, not a failure. A trial succeeds only when stress-ng exits 0, runs for at least 29 s of its 30 s window, writes a positive links-createdremoved-per-sec value to out.yaml, passes the twenty-millisecond /proc/uptime gate, and the sandbox is confirmed destroyed.

Step	Time Limit
Create	5 min
Hard Links	2 min
Destroy	5 min

Statistics

Based On

Common Methodology

Per-unit percentiles, bootstrap confidence intervals, and tail rules follow Common Methodology.

A provider is ranked once it has at least 20 successful trials.

Sandbox and Trials

Image Digest

sha256

Image Version

0.3.11

Image Registry Page

View on the Registry

Pull the Image

docker pull ghcr.io/boxrouter/standard-image@sha256:89d4c97048dbdfb8b6d85ad91833962ff38d1c334a5f47e6de80a9762310191b Copy

Lifetime

10.0 min

Idle Connection Time

5.0 min

From Common Methodology

Idle Connection Exceptions

Provider	Rule	File Transfer Idle Time
Daytona	The SDK has no idle-timeout setting. Its command channel keeps its connection open, and its file-transfer channel reconnects after 5 s of idle time.	5.0 s

From Common Methodology

Network Path Attempts

10

From Common Methodology

Mode

Single

Sandboxes per Trial

1

Parallel Trials

10

Concurrent Sandboxes

1

At a Glance

Metrics

• Hard Links
• Hard Links (2 vCPU / 8 GiB)

Quantity

Links

Unit

Hard-Link Rate (links/s)

Direction

Higher Is Better

Statistic

Median

Clock

Sandbox clock

From Common Methodology

Machine Size

2 vCPU / 4 GiB

Trials

75