Managing RAID on Linux

Journaling Filesystems

Journaling offers improved filesystem reliability and fast crash recovery through the use of a transaction log, or journal. The journal is an on-disk log of metadata, or data about the filesystem, that is kept up-to-date as the filesystem changes.

Filesystems without journaling store changes to the updates in memory. These changes are periodically flushed from memory and written to disk. If a crash occurs before the buffers are flushed, data that has not been written to disk is lost. Instead of storing these changes in memory, a journaling filesystem writes a log of the changes to disk. The actual data is kept in memory until enough free system resources are available so that the full write operations can be performed efficiently. When the data is committed to disk, the journals are updated.

The journal allows a filesystem to instantly recover to the last good state after a system crash. After the system reboots, outstanding consistent entries in the journal are replayed (committed to disk), while any remaining inconsistent entries are discarded. This process is often referred to as a log replay. The benefit here is that you don’t have to wait for a large filesystem to fsck. Journaling is especially helpful when working with RAID because arrays tend to be larger than single disks, which already take a long time to fsck. Imagine waiting for fsck to complete on a terabyte RAID partition that is using ext2. The downtime could be hours, or even days! With a journaling ...