“Journaling filesystems are superior to static filesystems
when it comes to guaranteeing data integrity and even when it comes
to flat-out filesystem performance. Replacing the ext2fs static
filesystem with a journaling filesystem will ultimately be a big
win for all Linux users.”
“When a Linux box is rebooted, it runs a program called fsck
(filesystem consistency check) that walks through the entire
filesystem, validating all entries and making sure that blocks are
allocated and referenced correctly. fsck would find the corrupted
directory entry and attempt to repair it. However, there is no
guarantee that fsck will actually be able to repair the damage. …
On a machine with many gigabytes of files, fsck can run for up to
20 minutes per filesystem.”
“Journaling and logging filesystems solve many of these
problems. Journaling and logging filesystems can either keep track
of the changes to a file’s “metadata” (information such as
ownership, creation dates, and so on), or to the data blocks
associated with a file, or to both, rather than maintaining a
single static snapshot of the state of a file. … Journaling and
logging filesystems get around the problem of inconsistencies
introduced during a system crash by using the log. Before any
on-disk structures are changed, an “intent-to-commit” record is
written to the log. The directory structure is then updated and the
log entry is marked as committed. … After a crash, filesystems
can come online almost immediately because only the log entries
after the last checkpoint need to be examined. Any changes in the
log can be quickly “replayed,” and the corrupted part of the disk
will always correspond to the last change added to the log. The log
can then be truncated since it will be invalid, and no data is lost
except for any changes that were being logged when the system went
down.”