Important NTFS uses transaction logging and recovery to guarantee that the volume structure is not corrupted. For this reason, all metadata files remain accessible after a system failure. However, user data can be lost because of a system failure, a bad sector, or a simple delete operation that is initiated by a user. NTFS does not implement transactional logging to protect user data. Regular backups of data are highly recommended.
NTFS Transaction Log Recoverability
Each file on an NTFS volume is listed as a record in the MFT. The first record in the table describes the MFT itself, and the second record describes a special file that mirrors the first few entries of the primary MFT. If the first MFT record is corrupted, NTFS uses the second record to find the MFT mirror file that is stored at the end of the logical disk, in which the first record is the same as the first record of the MFT. The boot sector records the locations of both the MFT and MFT mirror files. The MFT mirror file does not contain 100 percent of the whole MFT. Instead, it contains only the first few critical entries that Windows must have to mount the volume.
The third record in the MFT is the log file that records all file transaction information. NTFS and the Log File Service use the DATA attribute of the log file to implement file system recoverability. The Log File Service is a component of Windows NT Executive. Because the log file is a system file, it can be found early in the startup process and used to recover the disk volume if the volume is found to be corrupted. When a user updates a file, the Log File Service records all redo and undo information for the transaction. For recoverability, redo information allows NTFS to roll the transaction forward (repeating the transaction), and undo allows NTFS to roll the transaction back if an error occurs.
Committing data to the disk involves the following steps:
-
NTFS writes a log file record that notes the volume update that it intends to make.
-
NTFS calls the cache manager to flush the log file record to disk.
-
NTFS writes the volume update to the cache, modifying the cached metadata.
-
The cache manager flushes the modified metadata to disk, updating the volume structure.
-
NTFS writes a log file record that flags the transaction as having been completed.
If a transaction is completed successfully, NTFS commits the file update to disk. If the transaction is not completed, NTFS ends or rolls back the transaction according to the undo information. If NTFS detects an error in the transaction, it rolls back the transaction. If NTFS cannot guarantee that a transaction completed successfully, it rolls the transaction back. Incomplete modifications to the volume are not permitted.
If the system crashes (because of a power failure or other cause), NTFS performs three passes through the log on the disk: an analysis pass, a redo pass, and an undo pass. During the analysis pass, NTFS appraises the damage, if any, and determines which clusters it must update by using the information in the log file. The redo pass performs any steps that were logged from the last checkpoint. The undo pass then rolls back any incomplete (uncommitted) transactions.
The NTFS recovery pass involves the following steps:
-
When Windows recognizes an NTFS volume, it reads the MFT.
-
NTFS calls the Log File Service to open the log file. This causes the Log File Service recovery to occur.
-
NTFS calls the Log File Service to read its restart area and reads all the data from the last checkpoint operation. This data initializes the transaction table, dirty pages table, and open file table so that they can be used in the recovery process.
-
NTFS performs an analysis pass on its last checkpoint record. At the end of this pass, the transaction table contains only transactions that were active when the crash occurred.
-
NTFS performs a redo pass. At the end of this pass, the cache reflects the state of the volume when the crash occurred.
-
NTFS performs an undo pass. At the end of this pass, the volume is recovered to a stable state.
The Log File Service maintains two objects to support its functions:
-
The restart area. This is a status area used to transfer information about a client's last checkpoint operation before a crash to the client's recovery procedure. The Log File Service maintains two restart areas to guarantee that at least one valid area is always available.
-
The infinite log file. The log file is a circularly reused file. When a new record is added, it is appended to the end of the file. When the log file reaches its capacity, the Log File Service waits for writes to occur and frees space for new entries. This can be a very time-consuming operation. If the log file becomes full, there is a perceptible pause in file system activity. This can significantly degrade performance if it occurs repeatedly. If your system is prone to this behavior, make its log file bigger by using the chkdsk /l command (see “Chkdsk Syntax and Optional Command-Line Switches” 10 of this white paper), or consider how I/O might be rebalanced.
|
