Note that when reopening the log file, CLFS doesn’t know exactly where the log end LSN is, so it must find the LSN to avoid losing data or using corrupted data. For a dedicated log, CLFS reads the log blocks sequentially until an invalid log block is found and then sets the end of the log there. For a multiplexed log, CLFS reads the last owner page (the base log file saves a copy of the last flushed owner page’s LSN when the log metadata is last flushed) and verifies it is indeed valid. CLFS then reads the next region’s owner page repeatedly until an invalid owner page is found. After that, CLFS scans backward to find the first region with only valid log data blocks. CLFS then assumes the end of the log must fall within the next region. It will scan log block by log block until an invalid log block is found and then set the end of the log there.
Translating Virtual LSNs to Physical LSNs
CLFS relies on physical LSNs to identify log blocks within a physical log. However, CLFS combines several virtual logs in a physical log for multiplexed logs and uses virtual LSNs to locate log blocks in a virtual log. Therefore, for a virtual log client, a log block can be addressed both by a physical LSN and by a virtual LSN.
To translate a virtual log LSN to a physical log LSN, CLFS follows these steps:
Reads the owner page for the region indicated by the virtual log LSN.
Checks the owner page’s virtual LSN region to see whether the virtual LSN is actually in the region or not. Most of the time the log block will be in the region.
If the virtual LSN is in the region, CLFS refers to the
If the virtual LSN is not in the region, CLFS searches either the previous region or the next region depending on whether the virtual LSN is smaller or larger than the current region’s virtual LSN range.
Management Policies
Each CLFS log can be defined by a set of management policies that are configurable by the client. Table 12-5 lists these policies and their usage.
Policy Name
Description
ClfsMgmtPolicyMaximumSize
Specifies the maximum size of a log.
ClfsMgmtPolicyMinimumSize
Specifies the minimum size of a log.
ClfsMgmtPolicyNewContainerSize
Specifies the size of new containers that are created.
ClfsMgmtPolicyGrowthRate
Specifies how many new containers will be added to the log each time the log grows. Can be specified as either a relative percentage or an absolute number.
ClfsMgmtPolicyLogTail
Specifies how much free space will be requested when a client is notified to move its log tail. Can be specified as either a minimum percentage of free space or a minimum number of containers.
ClfsMgmtPolicyAutoShrink
Specifies when the log will shrink based on the percentage of the log that is free.
ClfsMgmtPolicyAutoGrow
Specifies whether the log should grow when fewer than two containers are free.
ClfsMgmtPolicyNewContainerPrefix
Specifies a prefix for the file name of each container, as well as the full path to the directory where the containers are located.
NTFS Design Goals and Features
In the following section, we’ll look at the requirements that drove the design of NTFS. Then, in the subsequent section, we’ll examine the advanced features of NTFS.
High-End File System Requirements
From the start, NTFS was designed to include features required of an enterprise-class file system. To minimize data loss in the face of an unexpected system outage or crash, a file system must ensure that the integrity of its metadata is guaranteed at all times; and to protect sensitive data from unauthorized access, a file system must have an integrated security model. Finally, a file system must allow for software-based data redundancy as a low-cost alternative to hardware-redundant solutions for protecting user data. In this section, you’ll find out how NTFS implements each of these capabilities.
Recoverability
