pub enum FlushMode {
Default,
Data,
MinMetadata,
NoSync,
}Expand description
How much a flush is asked to push, and whether it syncs the device at all
(M12.4, D-25 in DESIGN-NOTES.md).
This is BuildIoRingFlushFile’s FILE_FLUSH_MODE parameter, which the
crate previously hardcoded to FILE_FLUSH_DEFAULT. Exposing it is the
other half of D-25: the kernel offers a durability parameter here and a
wrapper that hides it narrows the platform to what its own examples needed.
FlushMode::Default is what a caller closing an epoch wants, and is
what the crate did before this existed.
§NoSync is not a durability operation
Three of these four modes issue the device sync; FlushMode::NoSync does
not. That is worth stating rather than inferring, and the inference runs
the other way too: the existence of a distinct “no sync” mode is the
evidence that the other three do sync. Nothing in the Win32
documentation says so directly.
Variants§
Default
FILE_FLUSH_DEFAULT: flush the file’s data and metadata, and sync the
device.
The default, and the mode a durability barrier wants. Pair it with
FlushCoverage::CoversPrecedingOperations or it covers nothing.
Data
FILE_FLUSH_DATA: flush the file’s data, and sync the device.
Metadata that is not required to read the data back may be left
unflushed. The analogue of fdatasync, and the usual choice for a log
whose records are self-describing.
MinMetadata
FILE_FLUSH_MIN_METADATA: flush the data plus the minimum metadata
needed to retrieve it, and sync the device.
NoSync
FILE_FLUSH_NO_SYNC: flush to the device without issuing the sync.
This is the one mode that makes nothing durable. It pushes data out of the system cache and stops there, so anything still held in a volatile device cache is lost on power failure exactly as if no flush had been issued at all. A completion from this mode is not a commit point and must never be reported to a caller as one.
It is useful for shaping when cache pressure is paid – moving data
deviceward early so a later real flush is short – which is the same
role WriteCaching::WriteThrough plays on the write side, and it
carries the same warning: a latency knob, not a durability primitive.