Journaling file system

[1][2] Depending on the actual implementation, a journaling file system may only keep track of stored metadata, resulting in improved performance at the expense of increased possibility for data corruption.

Alternatively, a journaling file system may track both stored data and related metadata, while some implementations allow selectable behavior in this regard.

This makes it possible for an interruption (like a power failure or system crash) between writes to leave data structures in an invalid intermediate state.

Detecting and recovering from such inconsistencies normally requires a complete walk of its data structures, for example by a tool such as fsck (the file system checker).

To prevent this, a journaled file system allocates a special area—the journal—in which it records the changes it will make ahead of time.

Some file systems may also allow external journals on a separate device, such as a solid-state drive or battery-backed non-volatile RAM.

A physical journal logs an advance copy of every block that will later be written to the main file system.

Physical journals impose a significant performance penalty because every changed block must be committed twice to storage, but may be acceptable when absolute fault protection is required.

To recover from these leaks, the free space map is reconciled against a full walk of the file system at next mount.