hesela.devStorage cache barrier
A storage cache barrier constrains persistence order across groups of writes without itself requiring those writes to be durable when it returns.
BarrierFS combines device support with host scheduling and dispatch changes; fbarrier() separates ordered recovery from durable completion. Its barrier flag closes an epoch, while writes inside that epoch may be reordered. Treat these as research-stack interfaces, not portable replacements for fsync(). [1]
Linux REQ_PREFLUSH instead persists previously completed writes before the accompanying I/O; REQ_FUA makes its own write persistent before completion. [2]
Hesela's four-record illustration enumerates possible states, not crash probabilities. Across epochs [A,B] then [C,D], durable D implies A and B, but need not imply C. The model excludes torn writes, overwrites and media faults. [3]
Relations
Advantages
- Separating order from completion permits deferred persistence between durability boundaries. [1]
Limitations
- An ordering guarantee alone cannot justify a durable acknowledgement. [1]
- Do not infer support from a generic SSD label or substitute the research API into an unchanged stack. [1]
Citations
- Youjip Won et al. Barrier-Enabled IO Stack for Flash Storage. FAST 2018, pp. 211-226; sections 3.2, 3.4 and 4.1-4.3.
- Linux kernel documentation: Explicit volatile write back cache control.
- Hesela: cache-barrier epochs and durable completion, with a constructed enumeration.
Sources & caveats
- Source synthesis; no hardware experiment or performance replication. Section 3.2 has an apparent before/after wording reversal; the interpretation follows sections 3.4 and 4.1-4.3, not that isolated sentence. No author-issued erratum is claimed.