Fast Topic Selection

FAST Topic Selection

Decide the venue before drafting. FAST — the USENIX Conference on File and Storage Technologies — is the storage-specialized flagship: its reviewers are file-system, SSD/NVM, key-value, caching, and reliability people, and they read for a storage contribution, not a general systems result that happens to touch disk. A technically strong paper whose real lesson is about scheduling, networking, consensus, or an ML model is respected and then routed to OSDI, ATC, or NSDI.

The routing question that matters most

The decisive question is rarely "is this systems work?" but "is the core lesson a storage lesson — about how data is laid out, written, cached, made durable, or kept consistent — that a storage reviewer would recognize as theirs?" If yes, FAST. If the storage angle is incidental to a broader OS/distributed/networking result, a general-systems venue fits better.

Sibling-venue routing table

Storage-contribution shapes FAST rewards

• New storage-system design — a file system, KV/object store, cache, dedup or tiering system designed around a media or workload reality, embodied and evaluated on real devices (the F2FS lineage).
• Media-conscious mechanism — a data-layout, compaction, wear, or scheduling change that removes a storage cost (write amplification, tail latency, endurance) measured on real hardware (the WiscKey lineage).
• Measurement / characterization methodology — a way to observe or model a device or system property that was opaque, validated against ground truth (the Skylight / SHARDS lineage).
• Large-scale reliability or field study — what actually happens to storage hardware or software at scale, with data no lab experiment could produce (the flash-reliability lineage).
• Storage correctness — crash consistency, durability, or data-integrity techniques and the tools that test them — a distinctly prized FAST mode.

The storage-lesson and re-label tests

Two quick tests sharpen a borderline verdict:

• Storage-lesson test: state your contribution in one sentence. If that sentence names a storage quantity or property (write amplification, endurance, crash consistency, miss ratio, layout, durability), FAST fits. If the storage word is removable without loss, route to a general-systems venue.
• Re-label test: could this paper go to OSDI or ATC unchanged and read as native there? If its heart is a scheduler, a runtime, or a protocol with storage as a case study, route accordingly; FAST rewards the paper whose core is storage.

Evidence maturity, without the ladder cliché

Fit is necessary but not sufficient: the same idea sits at different doors depending on how far the evidence has come. A provocative measurement with an argument but no system is a HotStorage paper; a design evaluated only on a simulator or one fresh-out-of-box drive needs real, aged devices under real workloads before the FAST bar; a study too deep for the page limit belongs in ACM TOS first. Submitting one step early earns a polite "promising, but measure it for real," and — because FAST runs only twice a year — costs months.

Cheap reconnaissance before committing

[Scope]   scan the last two FAST programs (dblp conf/fast, usenix.org) for your subarea
          -> 3+ recent papers = a reviewer pool exists; 0 = opening or mismatch (or it's an OSDI/ATC topic)
[Citations] is your bibliography majority storage venues (FAST/OSDI/ATC/EuroSys/HotStorage/MSST/TOS)?
          -> majority non-storage => reviewers read you as a visitor; naturalize the framing first
[Calendar] which FAST deadline (Spring/Fall) is next, and does an OSDI/ATC/EuroSys date land sooner?
          -> route to the nearest honest fit; FAST's twice-a-year rhythm cuts both ways

Decision procedure

[Audience]   who acts differently if the claim holds? storage engineers/researchers/operators?
[Claim type] storage-system design / media-conscious mechanism / measurement / reliability / correctness
[FAST vs OSDI/ATC] is the CORE lesson storage? -> FAST; is storage incidental? -> general-systems venue
[Sibling check] network core -> NSDI; early/position -> HotStorage; too long -> ACM TOS
[Calendar]   choose the nearer of the two FAST deadlines, or a sibling if it lands sooner
[Verdict]    USENIX FAST / sibling venue / workshop / journal, with a one-line storage reason

Run this before the writing skills; a wrong venue decision wastes every later step. When the verdict is FAST, continue with fast-workflow for the two-deadline calendar and fast-writing-style for the paper shape.