Once you have recovered your Mac from a crash/freeze/kernel panic/whatever, one of the first questions you should be asking is whether that resulted in any damage to its disk(s).

There are many layers between an app calling for the contents of a disk to be changed, and that change actually being completed. Most actions require a sequence of steps to be performed in the correct order. So at any moment in time, there may be a queue of actions pending.

When disaster strikes your Mac suddenly, chances are that some actions will still be pending. Before Apple introduced journalling to the Mac OS Extended File System (HFS+) used on your disk(s) since OS X 10.2.2 in 2002, this would often leave the disk(s) in a mess, resulting in disk errors. For example, if in the instant before a freeze, an app was in the process of making a copy of a file, the new copy (which it would be writing at the time) may not have been properly written and added to the disk’s directory structures.

Over time, those usually minor errors would accumulate, so that after a few such crashes, they would become significant enough to cause more substantial problems on the disk, which then required more serious repair.

The journal is intended to prevent that from happening. Each disk write is logged in that disk’s journal as soon as it is called. As the write actions are completed, they are removed from the pending list. If a crash forces your Mac to restart, early during the startup process macOS looks at the journal to see what actions were pending and have not been completed. It then steps through those actions, ‘replaying the journal’, until the disk has been brought up to date or synchronised with the journal, and reflects the state after the last journal entry.

Journal replays can only occur on volumes for which journalling is turned on. When it was first introduced, journalling was an option; it is now the default and you would be most ill-advised to turn it off.

The snag with HFS+ journalling is that it is aimed not at protecting data being written to files, but the directory structures and other essential information which makes the file system work. In the example given, when your Mac restarts it will correct those directories and should ensure that the drive works normally, but the data in a modified file may be junk, leaving the file corrupted. This may seem a serious omission, but it allows journalling to be much more efficient and effective.

macOS does not normally tell you in an alert when there is a problem with the journal, nor when it replays the journal to bring the disk back into sync. When you restart or start your Mac, macOS runs a quick check on the disks, using the command shell version of Disk Utility, fsck. That will normally indicate whether the journal looks to be in sync. If it is, macOS carries on starting up.

If that quick check shows there is a problem with the journal, then it will replay the journal to apply the necessary corrections. This is marked in your logs by entries looking like
jnl: disk0s2: replay_journal: from 13043200 to: 3971072 (joffset 0x15502000)

This reports that fsck found asynchrony in the journal of disk0s2, so called jnl to replay the actions which were needed. After that, your disk should be fully healthy again, and you should not need to perform any further repairs.

A good way to check this is to leave macOS to settle a bit after such a restart, then open Console, and search using the term jnl in the search box at the top right of the window. Once you have located the most recent line containing jnl, select it, then delete the jnl search term. The full logs will be revealed, for the time at which that line entry was made.

Rarely, there may be more severe damage which prevents journal replay, or which causes an error when trying to use the journal. You may then see log entries like
jnl: disk0s2: update_fs_block: failed to update block 2 (ret 5)
or
jnl: disk0s2: journal_open: Error replaying the journal!

The best action then is to restart in Recovery mode (Command-R at startup). This should automatically run a more powerful pass of fsck which should have a better chance of fixing the problems. Then switch to Disk Utility, and perform First Aid on the affected disk(s). If that cannot repair the damage, consider third-party disk repair tools such as DriveGenius, or you may even have to initialise the disk and reinstall.

Much of the time, journalling works effectively to prevent problems from occurring, and to prevent their building up to a full-blown disk crash. The good news is that Apple’s new APFS file system, which is intended for release in 2017, does not need this type of journalling, and should make disks more robust against the sort of problems that can arise from crashes. We will see if it does.