This comparison table is taken from the book “Architecture and Design of the Linux Storage Stack” which I find useful to help understand the differences between the two.
Journaling
Copy-On-Write
Write handling
Changes are recorded in a journal before applying them to the actual file system
A separate copy of data is created to make modifications
Original data
Original data gets overwritten
Original data remains intact
Data Consistency
Ensures consistency by recording metadata changes and replaying them if needed
Ensures consistency by never modifying the original data
Performance
Minimal overhead depending on the type of journaling mode
Some performance gains because of faster writes
Space utilisation
Journal size is typically in MB, so no additional space is required
More space is required due to separate copies of data
Recovery times
Fast recovery times as the journal can be replaced instantly
Slower recovery times as data needs to be reconstructed using recent copies
Features
No built-in support for features such as compression or deduplication
Built-in support for compression and deduplication
Taken from “Architecture and Design of the Linux Storage Stack”
The journaling file system (JFS) is a kind of file system developed by IBM IN 1990. It keeps track of changes, which are not yet committed to the file system’s main part, by recording the goal of such changes in a data structure known as “journal”. Usually, the “journal” is a circular log.
In the event of a system crash or power failure, a journaling file system can be brought back online more quickly with a lower chance of being corrupted. Depending on the actual implementation, the JFS may only keep track of stored metadata, which results in improved performance at the expense of increased possibility for data corruption.
Here is a diagram taken from Architecture and Design of Linux Storage Stack by Muhammad Umer Page 57
According to the Chapter 3 of the book,
From the diagram, any changes made to the filesystem are written sequentially to a journal, also called a transaction. Once a transaction is written to a journal, it is written to an appropriate location on a disk. In the case of a system crash, the filesystem replays the journal to see whether any transaction is incomplete. When the transaction has been written to its on-disk location, it is removed from the Journal.
It is interesting to note that either the metadata or actual data is first written to the data. Either way, once written to the filesystem, the transaction is removed from the journal. The size of the journal can be a few megabytes.
Benefits of Journal File System and Impact on Performance
Besides making the Filesystem more reliable and preserving its structure in system crashes and hardware failures, the burning question is whether it will impact performance?
Generally, journaling improves performance when it is enabled by having fewer seeks to the physical disks as data is only when a journal is committed or when the journal fills up. For example, in intense meta-data operations like recursive operations on the directory and its content, journaling improves performance by reducing frequent trips to disks and performing multiple updates as a single unit of work.