fast-experiments
Use when designing or auditing a USENIX FAST storage evaluation, covering real devices and firmware, device-state control (aging, preconditioning, fill, TRIM), standard workloads and traces (SNIA IOTTA, YCSB, filebench, fio), write amplification, tail latency, endurance and wear, crash-consistency testing, fair baselines, and matching the metric to the shape of each storage claim.
Profile →npx skills add brycewang-stanford/Awesome-Journal-Skills --skill fast-experiments --agent claude-code
Same command for any agent — swap --agent for codex, cursor, copilot.
Weekly change comes from our own snapshots, not the repository page — it measures attention, not adoption.
# FAST Experiments Use this before submission when the storage evaluation is not yet locked. FAST reviewers are storage people; the evaluation is where a good idea is won or lost, and the questions are storage-specific. The organizing principle is **measure the storage cost you claim to change, on real hardware in a realistic state** — not a throughput bar on a fresh drive. ## Evaluation audit - **Match the metric to the storage claim.** A claim about *endurance* needs bytes-written / P/E cycles, not throughput; a claim about *responsiveness* needs **tail latency** (p99/p99.9), not the mean; a claim about *space* needs measured on-media footprint; a claim about *durability* needs a crash-consistency test. The wrong metric is the most common FAST reject. - **Use real devices, and name them.** Model, capacity, interface (SATA/SAS/NVMe), and — critically — **firmware version**, plus host, kernel, and filesystem/mkfs options. Nominally identical drives differ part-to-part and across firmware; a result without the device table is not auditable. - **Control device state.** SSDs must be **preconditioned to steady state** (fresh-out-of-box numbers flatter every design); report fill level a
- Evaluation audit
- Claim-to-evidence design table
- Device-state and measurement floor
- Crash-consistency and durability testing
- Provenance floor for traces and field studies
- Vignette: evaluating a compaction change for a KV store
- Output format
What does the fast-experiments skill do?
Use when designing or auditing a USENIX FAST storage evaluation, covering real devices and firmware, device-state control (aging, preconditioning, fill, TRIM), standard workloads and traces (SNIA IOTTA, YCSB, filebench, fio), write amplification, tail latency, endurance and wear, crash-consistency testing, fair baselines, and matching the metric to the shape of each storage claim.
How do I install it?
Run `npx skills add brycewang-stanford/Awesome-Journal-Skills --skill fast-experiments --agent claude-code` — it drops the skill into your project so the agent can pick it up. Swap the --agent value for codex, cursor or copilot if you use one of those.
Where does this skill come from?
From brycewang-stanford/Awesome-Journal-Skills, a repository with 909 stars. We read it straight from the repository tree rather than a submitted listing, so what you see here is what is actually published.
Is a popular skill a good skill?
Not necessarily. Stars measure attention, not adoption — a repository can trend for a week and be abandoned. That is why we show the weekly change from our own snapshots next to the total, instead of a single flattering number.