Explicit Flush of Deferred Writes¶

An explicit storage-layer operation that selects earlier deferred writes and establishes a documented transfer, cache-flush, or ordering boundary for that set.

Version: v1 · 2026-10-25 · History
Domain-specific #: 14392
Domain group: Applied Sciences & Engineering
Origin domain: Computer Science & Software Engineering
Subdomains: Storage Systems, Filesystem IO → Computer Science & Software Engineering

Core Idea¶

Explicit flush of deferred writes is an operation at a named storage layer. That layer has accepted earlier writes whose effects may still reside in volatile state. A caller selects an eligible set of those earlier writes and explicitly asks the layer to advance them across its documented transfer or cache-flush boundary. The effect depends on the interface, the layer, and successful completion under its contract; the name alone is no guarantee about all caches or every failure mode.

Linux offers two distinct instances. The file-synchronization call fsync(fd) transfers modified data and metadata for a selected file and waits until the device reports completion; it returns a success or error result.^[1] At the block-device layer, a pure preflush request flushes previously completed writes in the device's volatile cache without carrying a dependent I/O.^[2] Linux expresses the latter as an otherwise empty bio marked REQ_PREFLUSH.^[2] These are unlike layer contracts that share the prior-write-set operation. They are documented interface cases, not measurements of two physical deployments.

The operation is narrower than write-back caching itself. Caching creates the opportunity to defer writes; explicit flushing chooses a later boundary for a defined earlier set. Forcing a newly submitted critical write does not by itself flush older dirty writes. REQ_FUA, for example, controls completion of the flagged current write, whereas REQ_PREFLUSH addresses previously completed writes in a device cache.^[2]

Structural Signature¶

The recurring roles are: named volatile layer → eligible earlier-write set → explicit synchronization request → bounded layer-specific effect.

Named write-back layer. State whether the claim concerns a filesystem's cached file data or a block device's volatile write cache. The layer determines which writes can be selected and which failure boundary is at issue. A device may report a write complete while retaining its data in volatile cache.^[2]
Eligible earlier-write set. Identify the writes already accepted at that layer but still requiring transfer or cache flush. The file-sync scope is modified in-core data and metadata of the named file.^[1] A pure device flush instead concerns previously completed writes in the device cache, not unsent host pages.^[2]
Explicit synchronization request. The caller invokes fsync for a file or syncfs for its filesystem.^[1]^[3] A separate pure block preflush request addresses the device cache.^[2] Background writeback alone is not a caller-selected boundary.
Bounded effect contract. The file call waits for device-reported transfer and returns status.^[1] The empty-bio preflush requests a device-cache flush; the cited kernel description does not define an fsync-like user-visible return contract for the pure helper.^[2]

Remove the earlier-write set and the request becomes current-write forcing; remove the named layer and “flush” ceases to specify a testable effect; remove the explicit operation or effect contract and ordinary eventual writeback is all that remains.

What It Is Not¶

It is not a promise that every acknowledged write everywhere survives a crash. File synchronization may leave its containing directory entry unsynchronized; a separate directory operation is needed when that entry is part of the persistence claim.^[1] The Linux manual also cautions that older kernels and some lesser-used filesystems may not flush a disk's internal cache without appropriate configuration.^[1] A pure device-cache flush does not reach backward into unsent host dirty pages or unfinished requests.^[2]

The prior-set flush differs from forcing a flagged current write; a preflush flag can also be attached to dependent I/O.^[2] The current-write flag is REQ_FUA.^[2] This entry makes no durable-media claim from C stream fflush, no home-page claim from database log forcing, and no persistent-media claim from CPU cache-line writeback. Each concerns a different layer or contract requiring its own evidence.

Scope of Application¶

Within Linux storage I/O, the operation occurs at file, filesystem, and block-device interfaces with different eligible sets. File fsync targets one file's modified data and metadata; filesystem syncfs synchronizes pending data and metadata on the filesystem containing its file descriptor.^[1]^[3] A pure device preflush targets previously completed writes in a device's volatile write-back cache.^[2] Its Linux block flag is REQ_PREFLUSH.^[2]

The Linux sync call waits for I/O completion, but its void return cannot report a per-call writeback error.^[3] POSIX permits the call to return after scheduling writes.^[3] Filesystem syncfs has a status return, with Linux 5.8 and later reporting writeback errors since the last call.^[3] These differences prevent treating all “sync” names as interchangeable success checks.

These interfaces can form parts of an end-to-end persistence path, but this entry does not infer a complete application or hardware guarantee from any one layer's operation. It applies when the selected earlier-write set and the interface's actual effect can be named.

Clarity¶

Ask four questions whenever someone says “the writes were flushed”: Which layer? Which earlier writes? Which operation? Which documented completion or ordering boundary? The answers distinguish a file's dirty pages from a drive's completed-but-cached requests. They also expose a common scope error: a successful file-data synchronization does not automatically establish persistence of the directory entry naming that file.^[1]

“Completion” is not one universal event.

The fsync call waits for the storage device to report transfer complete and has a result the caller can check.^[1] The kernel's description of a pure preflush establishes a device-cache flush effect.^[2] That description does not specify a user-visible success/error return for the pure helper; it cannot be borrowed from fsync.^[2] The difference should remain visible rather than being smoothed into one generic durability claim.

Manages Complexity¶

Deferred write-back lets a layer acknowledge or accumulate writes before they reach its nonvolatile backing medium. A storage path may have more than one such layer. The four-role test turns “flush the buffers” into a tractable obligation: inventory the eligible earlier set at one layer, invoke its explicit operation, and read the result only according to that interface's contract. A filesystem request and a device-cache request can be composed, but their scopes cannot be silently substituted.

This decomposition also localizes failures. If the necessary name-to-file directory update is outside a file fsync, add a directory operation.^[1] If the concern is device-cache contents, determine whether the request covers previously completed device writes rather than still-dirty host pages.^[2] If a program relies on Linux sync, its lack of per-call error return limits what a caller can conclude even though the Linux call waits for I/O.^[3]

Abstract Reasoning¶

To test an alleged instance, first choose the layer and the failure domain. List the older writes accepted at that layer and identify the operation's eligible subset. Then check whether an explicit request advances that subset to the documented boundary on successful completion. A request that only forces one new write fails the earlier-set test; a request that only schedules later work fails a completed-boundary claim.

Next, ask what would be observed if the operation were omitted. With a volatile device write cache, completion of earlier I/O can precede nonvolatile placement.^[2] A pure preflush is the documented operation for that already-completed device set.^[2] The inference is interface-bounded. It does not prove the device firmware honors the contract, or that other layers have already submitted all their writes.

Knowledge Transfer¶

The four-role test transfers within storage systems from a file's cached data to a block device's volatile write cache. The selected set, command, status reporting, and failure domain all change, while the prior-write-set question stays useful. The transfer is analytical: it lets one compare two layer contracts without claiming that fsync and pure REQ_PREFLUSH are equivalent commands or independent measurements.

Outside storage, “flush” can mean making output visible or clearing a buffer. That vocabulary resemblance does not establish this entry's documented nonvolatile-storage boundary. A more general pattern of choosing when deferred work must finish may exist elsewhere, but this storage-specific operation does not by itself establish a Prime.

Examples¶

Canonical: a Linux file synchronization¶

Suppose a program has modified a file and must check completion of those modifications before reporting its own operation complete. It calls fsync(fd) and checks the return value.^[1] On success, Linux says the call has transferred the modified file data and metadata and waited for the device to report completion.^[1] If the application also needs a newly created directory entry to persist, it separately synchronizes the containing directory.^[1] The example relies on the documented Linux interface and an honest device; it is not an empirical power-loss test.

Mapped back: named write-back layer → filesystem file-synchronization interface; eligible earlier-write set → modified data and metadata of the selected file; explicit request → fsync(fd); bounded effect → device-reported transfer plus a checkable success/error result, with the directory entry outside the file-only claim.

Applied: a pure block-device cache flush¶

At the Linux block layer, previously completed writes may still reside in a device's volatile write-back cache.^[2] An otherwise empty preflush bio is a standalone request to flush that cache; it has no dependent write to order.^[2] The block flag for this operation is REQ_PREFLUSH.^[2] By contrast, attaching a preflush to a new I/O orders previously completed writes before that I/O starts; forced unit access governs completion of the flagged current write.^[2] The latter flag is REQ_FUA.^[2] The kernel documentation establishes the pure flush effect without specifying a user-visible success/error return for the helper.

Mapped back: named write-back layer → volatile block-device cache; eligible earlier-write set → previously completed device writes resident there; explicit request → otherwise empty REQ_PREFLUSH bio; bounded effect → device-cache flush without dependent I/O, under the documented device/driver contract.

Structural Tensions¶

T1: deferred acknowledgment versus an explicit boundary. A device cache can acknowledge a write before nonvolatile placement, leaving a volatile gap.^[2] Requiring an explicit flush for a selected older set closes that named gap only by paying for transfer or cache flush at the chosen point.^[1]^[2] Both aims cannot be fully realized for the same prior set at the same instant: those bytes cannot remain solely volatile and already have crossed the requested boundary. Diagnostic: Which earlier writes must be advanced before the caller proceeds?

T2: narrow selection versus broad selection. File-scoped fsync can target the file whose content matters, while filesystem-scoped syncfs covers pending data and metadata across the containing filesystem.^[1]^[3] The broader choice may include writes outside the immediate application dependency; the narrower choice may omit a directory entry or another file the dependency actually needs. Neither scope is intrinsically right. Diagnostic: Is the required dependency one file's data, its name as well, or a filesystem-wide pending set?

The domain-specific autonomy question is distinct from these operating pressures. Calling this only “caching” loses the explicit earlier-set selection and documented boundary. Calling it a general Prime would erase filesystem and device contracts that decide what success actually means. This explanatory contrast is an identity test, not a third performance trade-off.

Structural–Framed Character¶

The actual selected set and effect of each Linux operation are specified by its interface.^[1]^[3]^[2]

The entry is structural within storage I/O and framed by its interfaces. Evaluative weight: it describes an operation, not a recommendation to flush as often as possible; correctness depends on the application's dependency and failure claim. Human-practice dependence: software deliberately places synchronization points, but the selected set and effects are defined by the storage interfaces. Institutional origin: Linux contracts are documented implementation conventions rather than laws of all storage devices. Vocabulary travel: “flush” is widely used, while file sync, filesystem sync, and device preflush have much narrower meanings. Import versus recognition: the caller invokes an operation, and an analyst recognizes an instance by its layer, earlier set, request, and effect. Its character is a repeatable technical procedure with contract-bounded results.

Structural Core vs. Domain Accent¶

The structural core is an explicit operation that advances a previously accepted, still-vulnerable set across a stated boundary at a named layer. Both examples retain that sequence despite their different objects and interfaces. The domain accent is constitutive: file metadata, directory entries, completed block requests, volatile device caches, error returns, and ordering flags determine what counts as the set and what the result permits one to conclude.

Removing those storage-layer semantics leaves a broad idea of finishing deferred work, but that broader phrase cannot answer whether a host page, file name, or device-cache entry was covered. Thus the demonstrated identity remains domain-specific. Its cross-domain reach is an analogy until another field supplies a literal comparable operation and evidence.

This entry presupposes Boundary.

Boundary is the typed parent: both examples require an operative demarcation between the named layer's eligible volatile set and its documented post-transfer or post-flush state. The interface selects what may cross, the effect matters only in one direction, and the stipulated rule can be stable even when an implementation's compliance is uncertain. The operation presupposes that demarcation; it is not itself a kind of Boundary.

Caching is a neighboring Prime: its storage examples include write-back, which can create the volatile lag this operation addresses. The explicit selected-set flush is not itself every cache. Buffering is another neighboring Prime because writes can accumulate before later transfer; its full rate-smoothing and stocked-decoupling signature is not required by an immediate single-write flush. Synchronization is a tempting name match, but its Prime identity concerns phase or timing alignment rather than this storage operation.

The domain-specific No-Force Policy is also nearby: it permits database commit before every modified home data page is forced, provided recovery information is stable. That page-force policy neither defines the file/device flush operation here nor proves that forcing a log writes the database pages. The two identities have different inputs and decisions.

Relationships to Other Abstractions¶

Current abstraction Explicit Flush of Deferred Writes Domain-specific

Parents (1) — outgoing typed relations

Explicit Flush of Deferred Writes presupposes Boundary Prime

The selected prior-write flush presupposes an operative storage-layer boundary that defines the eligible volatile set and its documented post-transfer or post-flush state.

Hierarchy path (1) — routes to 1 parentless root

Explicit Flush of Deferred Writes → presupposes Boundary

Neighborhood in Abstraction Space¶

Explicit Flush of Deferred Writes sits in a sparse region of the domain-specific corpus (94^th percentile for distinctiveness): few abstractions share its structure, so a faithful description tends to retrieve it precisely.

Family — Unclustered & Miscellaneous (2769 abstractions)

Nearest neighbors

Computed from structural-signature embeddings · 2026-10-25

Not to Be Confused With¶

Write-back cache with durable backing store names a broader solution mechanism that accepts writes quickly and later propagates them. Its exception lets a selected new critical write bypass the deferred path; that does not necessarily flush older dirty writes.

Current-write forcing is different: the block-layer FUA flag controls completion of the flagged write, not the earlier device-cache set.^[2] The kernel names the flag REQ_FUA.^[2]

Linux sync waits for I/O but returns no per-call status; unlike a successful fsync, it cannot itself provide a success-checked result.^[3]^[1] C stream fflush concerns another buffering layer; this entry makes no durable-media claim from it. Database log forcing concerns a log dependency; this entry does not infer that it forces home data pages. A claim about either operation needs evidence for its own layer.

References¶

[1] Linux man-pages project. “fsync(2), fdatasync(2) — synchronize a file's in-core state with storage device,” Linux man-pages 6.19 (8 February 2026), DESCRIPTION, RETURN VALUE, and HISTORY. https://man7.org/linux/man-pages/man2/fsync.2.html. Documents file-data and metadata scope, directory-entry qualification, device-reported completion, return status, and older-kernel/filesystem cache limits. registry ↩a ↩b ↩c ↩d ↩e ↩f ↩g ↩h ↩i ↩j ↩k ↩l ↩m ↩n ↩o ↩p ↩q

[2] Linux kernel documentation. “Explicit volatile write back cache control,” Introduction, Explicit cache flushes, and Forced Unit Access. https://docs.kernel.org/block/writeback_cache_control.html. Defines volatile device write-cache behavior, pure and attached preflush requests, and forced-unit-access behavior. registry ↩a ↩b ↩c ↩d ↩e ↩f ↩g ↩h ↩i ↩j ↩k ↩l ↩m ↩n ↩o ↩p ↩q ↩r ↩s ↩t ↩u ↩v ↩w ↩x ↩y ↩z ↩27

[3] Linux man-pages project. “sync(2), syncfs(2) — commit filesystem caches to disk,” Linux man-pages 6.19 (8 February 2026), DESCRIPTION, RETURN VALUE, ERRORS, VERSIONS, and HISTORY. https://man7.org/linux/man-pages/man2/sync.2.html. Distinguishes Linux sync, syncfs, POSIX scheduling, and Linux 5.8 writeback-error reporting. registry ↩a ↩b ↩c ↩d ↩e ↩f ↩g ↩h ↩i