Filesystems: Page Caches, Journals, and Durable Writes

A successful file write does not usually mean the bytes are durable. It often means the operating system copied them into memory and accepted responsibility for writing them later. A successful rename means a namespace change became visible atomically under defined conditions, but it does not automatically prove that the renamed file will survive sudden power loss. A journal can restore filesystem structure after a crash without preserving the latest application payload.

These are not implementation footnotes. They are separate guarantees: visibility to current processes, atomicity of a namespace operation, consistency after interrupted updates, and persistence across failure. Reliable file updates come from naming the guarantee an application needs, issuing operations in an order the filesystem supports, and testing that order under realistic failure assumptions.

Follow Bytes Through the Page Cache #

Ordinary buffered I/O passes through the kernel’s page cache. When an application writes to a regular file, the kernel resolves the descriptor and offset, validates the range, copies data into cached memory pages, marks those pages dirty, updates in-memory metadata, and may return. The storage device can still contain the previous bytes.

The page cache unifies several jobs. Reads can be served without visiting storage when the relevant pages are resident. Nearby reads may trigger readahead. Writes can be combined, reordered, and sent as larger requests. Multiple processes accessing the same file normally observe a coherent cached representation according to filesystem and mapping rules. Spare memory becomes an I/O accelerator rather than sitting unused.

Dirty pages cannot remain indefinitely. Background writeback selects them according to age, memory pressure, configured thresholds, and filesystem policy. A process that dirties data faster than storage can absorb it may eventually be throttled or block while reclaim and writeback catch up. That is backpressure at the memory-to-storage boundary: early writes appear fast because they consume a finite buffer, then latency rises once dirty capacity or device queues fill.

This behavior invalidates a common benchmark. Timing only the write calls for a data set that fits in memory can measure copying into cache, not storage throughput. A representative test must include the required synchronization point, run long enough to reach steady-state dirty limits, or explicitly state that it measures buffered acceptance. Dropping caches is not a universal cure; it changes the workload and often requires privileges, while real applications may intentionally rely on cache reuse.

Memory-mapped files also interact with cached pages. Stores through a mapping can mark pages dirty without an explicit write syscall. Mapping APIs have separate visibility and synchronization rules, and a language-level memory fence is not a storage flush. Applications must use the platform’s mapping synchronization and file durability operations where the contract requires them.

Separate File Contents from Filesystem Metadata #

A file is more than a byte array. Its persistent representation includes length, ownership, timestamps, allocation information, and links from directory names. Creating settings.json can require updates to the file’s data blocks, its inode or equivalent record, allocation structures, and the parent directory. Each piece may reach storage at a different time unless ordering is enforced.

That distinction explains why overwriting a file in place is risky. Suppose an application truncates an existing configuration and writes a new document. A crash after truncation but before all new pages persist can leave an empty, partial, or mixed-generation file. Even if each sector write is indivisible, a document spanning several sectors is not one atomic update.

Storage allocation adds another ordering concern. A filesystem must not expose stale bytes from a block previously owned by another file. It can initialize new data before publishing metadata that points to it, record the operation transactionally, or use another safe protocol. Filesystem ordering modes are designed partly around such invariants, but their guarantees differ. Application code should consume documented guarantees rather than infer them from one observed disk image.

Directory entries deserve equal attention. Creating, unlinking, or renaming a name modifies the directory. Synchronizing only the file may make its contents durable while leaving the new name vulnerable to crash recovery. Conversely, persisting a directory entry that points to file contents not yet synchronized can preserve the name with incomplete payload. A crash-safe update needs both layers in the right order.

Hard links, symbolic links, sparse extents, copy-on-write clones, checksums, encryption, and snapshots add more metadata paths. The durable protocol should remain minimal and documented because every assumed side effect is another filesystem- and platform-dependent contract.

Use Journaling to Recover Structural Consistency #

A filesystem update often touches several persistent structures that must agree. Without a recovery protocol, a crash between those writes could leave an allocated block marked free, a directory entry pointing to an uninitialized object, or a link count inconsistent with the namespace. Journaling protects a defined set of metadata or data changes by recording transaction information that recovery can replay or discard.

In a simplified metadata-journaling sequence, the filesystem prepares changed metadata, records a transaction in the journal, makes the journal transaction durable, later writes metadata to its home locations, and eventually reclaims journal space. After a crash, recovery finds committed journal transactions and replays updates that may not have reached home. Incomplete transactions are ignored. Real implementations use checksums, barriers, batching, revoke records, and other mechanisms, but the core goal is atomic recovery of filesystem invariants.

Journaling mode matters. A metadata-only journal protects structure while file payload is written separately. An ordered mode may ensure newly written data reaches its required location before metadata that exposes it is committed. A data-journaling mode can include payload in the journal at additional write cost. Copy-on-write filesystems use a different family of techniques, writing new tree nodes and switching roots rather than overwriting every structure in place. Neither label alone states an application’s durability guarantee.

The journal is not an unlimited history and is not a substitute for a database transaction. Recovery aims to produce a structurally valid filesystem, usually using the most recent committed filesystem transactions. It does not know that three application files together represent one business state unless the application builds a protocol for that invariant. It also does not guarantee that a write acknowledged only into page cache appears after power loss.

Ask Explicitly for Durability #

An application requests persistence with a synchronization operation such as fsync on an open file. Broadly, the call asks the kernel to write the file’s dirty data and required metadata and wait until the storage stack reports completion. A related data-only operation may omit metadata not needed to retrieve the bytes, while still persisting details such as length when necessary. Exact definitions vary by platform.

Ordering is the important property. If payload must be durable before a name points to it, synchronize the payload first, perform the namespace change, then synchronize the directory. Issuing all operations without waits can allow lower layers to reorder them unless the interfaces and filesystem provide dependencies or barriers. A successful sync is a protocol boundary, not merely a request to start writeback.

Even this guarantee has a hardware assumption. Devices and controllers may have volatile write caches and must correctly honor flush or force-unit-access commands. Filesystems and drivers translate sync operations into those mechanisms. Hardware that lies about completion, loses power outside its specified protection, or ignores cache-flush semantics can violate the stack’s promise. Applications generally rely on the operating system and supported storage rather than controlling devices directly, but operational claims should state that dependency.

Synchronization errors can surface late. Background writeback may discover media or remote-filesystem failure after an earlier buffered write returned. The application must check errors from write, close where its platform reports them, and especially synchronization. Retrying blindly can be unsafe if the underlying storage state is uncertain. Durable systems need an escalation path rather than treating fsync failure as a logging detail.

Calling sync after every tiny record can be prohibitively expensive because it prevents useful grouping and waits for persistence latency repeatedly. Group commit batches several logical records behind one synchronization boundary. This trades a bounded window of unacknowledged work and slightly higher per-record waiting for better throughput. The application must define whether acknowledgment occurs before or after the group is durable.

Replace a File Atomically and Durably #

Consider updating settings.json. The desired recovery invariant is simple: after a crash, readers see either the complete old document or the complete new document, never a partially overwritten one. A robust POSIX-style sequence writes a temporary file in the same directory, synchronizes it, atomically renames it over the destination, and synchronizes the parent directory.

function replace_durably(directory, final_name, bytes):
    temp_name = unique_name_inside(directory)
    temp = open(temp_name, create_exclusive, mode=restricted)

    try:
        write_all(temp, bytes)       # handle partial writes
        fsync(temp)                  # persist payload and required file metadata
        close(temp)

        rename(temp_name, final_name) # same-filesystem atomic replacement

        dir_handle = open_directory(directory)
        fsync(dir_handle)             # persist the namespace change
        close(dir_handle)
    on error:
        close_if_open(temp)
        unlink_if_present(temp_name)
        report_failure

Creating the temporary file exclusively prevents accidental reuse or symlink substitution. Keeping it in the destination directory normally keeps source and destination on the same filesystem, a prerequisite for atomic rename semantics. Restrictive initial permissions avoid briefly exposing sensitive bytes; ownership and mode changes that must survive should happen before the file sync.

The first synchronization establishes that the new file’s payload is persistent before it can become the public version. The rename changes the directory namespace atomically for concurrent readers under the platform’s replacement rules. The directory synchronization then makes that namespace update durable. If the process crashes before rename, the old destination remains and a temporary file may need cleanup. If it crashes after a durable rename protocol completes, the new destination should remain.

There are important limits. Exact replacement, directory sync, and open-handle semantics differ across operating systems, network filesystems, and unusual filesystems. Renaming across filesystems is generally a copy-and-delete operation rather than an atomic rename. This protocol updates one name, not several files as one transaction. It also does not coordinate concurrent writers: use locking, compare-and-swap through generation names, or another ownership scheme to prevent lost updates.

For immutable content, an alternative is to write a uniquely named durable object and atomically update a small manifest or pointer file. Readers validate the referenced generation. This can simplify cleanup and rollback, but the pointer update still needs the same durability reasoning.

Recognize Tradeoffs and Failure Modes #

Durability, latency, throughput, and storage wear pull in different directions. Frequent synchronization shortens the loss window but increases waiting and write amplification. Large buffers improve batching but increase memory and the amount of accepted-yet-not-durable work. Journaling or copy-on-write protects consistency but adds metadata traffic and can amplify writes under some patterns.

Atomicity is often overclaimed. A single aligned device write, a filesystem block update, a rename, and a multi-file business transaction have different atomic scopes. Appending records may avoid overwrite damage, but a crash can leave a torn or incomplete tail; readers need framing, lengths, checksums, and truncation rules. A checksum detects corruption but does not by itself restore the missing data.

Concurrent access creates another class of failure. Renaming a complete file gives new openers the new generation, while processes holding the old file descriptor may continue reading the old object. That can be desirable for lock-free readers. It does not guarantee that a reader opening several related files sees one common generation. Publish a manifest last or use a transactional storage system when cross-file snapshots matter.

Remote and virtual filesystems need special scrutiny. A client-side fsync may depend on server acknowledgment, protocol semantics, replication policy, and server storage. Container boundaries do not create durability; bind mounts, layered filesystems, and ephemeral volumes inherit their backing implementation. An API documented for a local filesystem should not be assumed equivalent on an object store mounted through a compatibility layer.

Operational shortcuts can break otherwise sound code. Disabling barriers, using unsupported device caches, acknowledging before sync to improve a dashboard, or restoring only the data file without its generation metadata changes the guarantee. Durability is an end-to-end property from application acknowledgment through recovery procedure.

Test Crash Consistency and Operate the Boundary #

Ordinary unit tests verify serialization and error handling but do not prove crash behavior. Build a model of permitted recovery states. For atomic replacement, initialize version A, attempt to publish version B, interrupt at many points, remount or restart the storage environment, and assert that the destination parses and equals exactly A or B. Temporary files may remain, but no partial public document is allowed.

Failure injection should cover short writes, out-of-space conditions, permission errors, sync failure, rename failure, directory-sync failure, and two concurrent publishers. Use a disposable filesystem image or virtual machine when testing abrupt power-loss behavior; killing only the application process tests process interruption, not loss of kernel page-cache contents. Storage fault tools and filesystem-specific test harnesses can exercise reordering and torn-write assumptions more directly.

Treat illustrative fault injection as evidence for one stack, not proof for every deployment. Record operating system, filesystem and mount options, kernel, virtual or physical device, cache policy, and recovery steps. Rerun after changing any of them. Network storage requires server-side failure tests and documented protocol guarantees.

In production, monitor dirty-memory pressure, writeback errors, synchronization latency distributions, device queueing, filesystem space and inode exhaustion, read-only remounts, and storage health. Alert on durable-operation failures immediately. Preserve enough generation metadata to determine which update was acknowledged, and rehearse recovery without silently choosing the newest timestamp.

The durable lesson is to stop using “written” as one state. Bytes may be copied into user memory, accepted into page cache, dispatched to a device, reported stable, linked under a public name, or recovered after a crash. Page caching makes ordinary I/O efficient, journaling restores filesystem invariants, synchronization establishes persistence order, and atomic rename publishes one complete generation. Correct software composes those mechanisms into the exact guarantee it promises and then tests the failure points between them.