fast-reproducibility

name	fast-reproducibility
description	Use when strengthening USENIX FAST reproducibility and open-science evidence, covering device and firmware provenance, device-state disclosure, trace availability and replay, claim-to-evidence mapping, honest degrees of reproducibility on hardware that ages and varies, and consistency between what the paper says and what the artifact contains.

FAST Reproducibility

Use this before submission and again before camera-ready. FAST's storage results live on real hardware that ages, throttles, and varies part-to-part, so reproducibility here is a distinct craft from software-only venues: a reader reproducing your work needs to know not just the code but the device, its firmware, and its state. The goal is that a competent reader with comparable hardware could rebuild your evidence and reach your conclusions.

Evidence map

• Map each claim and reported number to a verifiable location — a paper section, a table generated from a logged run, or a script in the artifact.
• For a system, give enough of the design, parameters, mkfs/mount options, and build environment that a reader could rebuild and run it.
• For measurements, report the device provenance (models, firmware, interface), the host (CPU, RAM, kernel), and the device state (steady-state/aged, fill, TRIM) — the storage-only provenance that software artifacts omit.
• Keep the availability statement truthful and specific: what code and traces are shared, where they will live after acceptance, and — if something cannot be shared — exactly why.
• Keep the paper and the artifact consistent: a bytes-written or latency number in the PDF that no script in the artifact regenerates is the contradiction reviewers read as carelessness.

Availability statement audit

Claim in the paper	Weak answer	FAST-ready answer
"We evaluate on SSDs A, B, C"	"Standard SSDs"	Exact models, capacities, and firmware versions in a testbed table
"Driven by trace T"	Trace named, not shared	Archived trace (or documented access) + the replay script and its settings
"We reduce write amplification"	Estimated in prose	Device-counter (SMART/log) dumps + the script that computes WA from them
"Steady-state results"	Unstated preconditioning	The preconditioning/aging protocol as a runnable script
"Our system is available"	"Code on request"	Anonymized, buildable code with a README and a small runnable demo

"Available on request" is treated as not available; convert every such line into a concrete, anonymized artifact or an explicit, justified exception (e.g. drives under NDA, privacy-limited production traces).

Provenance pinning

[Devices]   model, capacity, interface, FIRMWARE version; host CPU/RAM, kernel, mkfs/mount options
[State]     preconditioning/aging protocol, fill level, TRIM/discard; FOB vs. steady-state disclosed
[Traces]    archive the replayed trace or document access; ship the replay tool + timing settings
[Workloads] YCSB/filebench/fio job files with exact parameters and seeds
[Compute]   run duration and repeats; note thermal/throttling conditions that affect timing
[Counters]  how bytes-written / WA / GC were read from the device, so a reader can re-derive them

Degrees of reproducibility (state the one you achieved)

• Turnkey: one documented command regenerates a table/figure from logged data (best for analysis and plots).
• Scripted-on-hardware: scripts run end-to-end but require comparable devices and time (endurance runs, aging, long trace replays); document the hardware and expected runtime.
• Descriptive: prose and provenance detailed enough that a reader with the right hardware could rebuild the pipeline (acceptable for results that need specific or proprietary devices).

For FAST, aim turnkey for anything that runs from logged data, and be honest that device-bound results are scripted-on-hardware: state which drives, which firmware, and how long. Promising turnkey behavior that silently needs a specific SSD is worse than stating the hardware dependency.

The hardware-variance caveat (state it plainly)

Storage numbers are device- and firmware-specific; a reader on a different drive should expect the trend, not the exact factor. Say so, report per device rather than one blended number where it matters, and bound generalization — this is not a weakness to hide but the honest storage posture reviewers reward.

Vignette: a file-system aging study

Consider a study whose results depend on a fragmented, aged volume. Its reproducibility spine: the aging workload as a runnable script (so the fragmentation state is reconstructable), the exact mkfs/mount options and kernel, the device models and firmware, the measurement scripts that read from the device and file-system counters, and the analysis notebooks that turn logs into the paper's figures — plus one honest sentence about which numbers require the specific drives used.

Consistency and camera-ready pass

• Before submission: every scored number traces to the artifact; the availability statement matches reality; the artifact is anonymized (no owner strings, hostnames, cluster paths, or personal trace URLs).
• Before camera-ready: swap anonymized links for a permanent, licensed, DOI-issuing archive (Zenodo/figshare/Software Heritage) and align the statement with the USENIX artifact badges you are pursuing (fast-artifact-evaluation).

Output format

[Claim inventory] <claim -> evidence location>
[Availability] concrete / vague / missing
[Provenance gaps] <device+firmware / device state / trace archival / counters / seeds>
[Reproducibility level] turnkey / scripted-on-hardware / descriptive, stated honestly
[Hardware dependency] <which results need which drives/firmware, stated?>
[Paper fixes] <must appear in the PDF>
[Artifact fixes] <additions before upload>