Intent logging minimizes system downtime after abnormal shutdowns
by logging filesystem transactions. When the system is halted
unexpectedly, this log can be replayed and outstanding transactions
completed. The check and repair time for filesystems can be reduced
to a few seconds, regardless of the filesystem size.
NOTE:
Intent logging does not increase the reliability of filesystem.
Only transactions concerning file meta data (the structures concerned
with storing data) are logged. The purpose is to
minimize system downtime.
The ability to locate and check only affected areas of the disk for
inconsistencies is central to the logging mechanism. The structure of the
mechanism is:
A log file is created as special file in the root of each mounted
filesystem. (This file is normally invisible and
is neither readable nor removable when logging is enabled.
When logging is disabled on a previously enabled filesystem, the
log file appears as .ilog0000.)
The location of the file is kept in the superblock (an area at the top
of the filesystem structure which describes the attributes of the
filesystem in terms of type, size, available space and latest modification
time).
Changes to a file's meta data (as opposed to the data it contains)
such as inodes
and block bitmaps are cached in memory. Before making any changes on disk,
a log entry is written synchronously. After the changes are
performed, a ``transaction complete'' indication is stored on disk.
If the system crashes before the log is written, it is as if the
change (any modifications to the filesystem) never occurred. If the system
crashes after the log is written, but before the transaction complete,
fsck either completes the change or undoes it.
If the system crashes after the transaction is completed, then the
modification has been completed, and there is nothing for fsck to do.
NOTE:
For optimum benefit, both logging and checkpointing
should be enabled. Checkpointing marks the filesystem as clean whenever
the filesystem is inactive. If the system needs to be checked (in the event
of an abnormal system halt, for instance) only areas of the disk
manipulated since the last checkpoint operation need to be
examined for inconsistencies.