Page 389 - DCAP103_Principle of operating system

Principles of Operating Systems

Notes Record 1 is a duplicate of the early part of the MFT file. This information is so precious that
having a second copy can be critical in the event one of the first blocks of the MFT ever goes bad.
Record 2 is the log file. When structural changes are made to the file system, such as adding a
new directory or removing an existing one, the action is logged here before it is performed, in
order to increase the chance of correct recovery in the event of a failure during the operation.
Changes to file attributes are also logged here. In fact, the only changes not logged here are
changes to user data. Record 3 contains information about the volume, such as its size, label,
and version.

As mentioned above, each MFT record contains a sequence of (attribute header, value)
pairs. The $AttrDef file is where the attributes are defined. Information about this file is in MFT
record 4. Next comes the root directory, which itself is a file and can grow to arbitrary length.
It is described by MFT record 5.

Free space on the volume is kept track of with a bitmap. The bitmap is itself a file and its
attributes and disk addresses are given in MFT record 6. The next MFT record points to the
bootstrap loader file. Record 8 is used to link all the bad blocks together to make sure they never
occur in a file. Record 9 contains the security information. Record 10 is used for case mapping.
For the Latin letters A-Z case mapping is obvious (at least for people who speak Latin). Case
mapping for other languages, such as Greek, Armenian, or Georgian (the country, not the state),
is less obvious to Latin speakers, so this file tells how to do it. Finally, record 11 is a directory
containing miscellaneous files for things like disk quotas, object identifiers, reparse points, and
so on. The last 4 MFT records are reserved for future use.
Each MFT record consists of a record header followed by a sequence of (attribute header, value)
pairs. The record header contains a magic number used for validity checking, a sequence number
updated each time the record is reused for a new file, a count of references to the file, the actual
number of bytes in the record used, the identifier (index, sequence number) of the base record
(used only for extension records), and some other miscellaneous fields. Following the record
header comes the header of the first attribute, then the first attribute value, the second attribute
header, the second attribute value, and so on.
NTFS defines 13 attributes that can appear in MFT records. These are listed in Figure 13.6. Each
MFT record consists of a sequence of attribute headers, each of which identifies the attribute it
is heading and gives the length and location of the value field along with a variety of flags and
other information. Usually, attribute values follow their attribute headers directly, but if a value
is too long to fit in the MFT record, it may be put in a separate disk block. Such an attribute is
said to be a non-resident attribute. The data attribute is an obvious candidate. Some attributes,
such as the name, may be repeated, but all attributes must appear in a fixed order in the MFT
record. The headers for resident attributes are 24 bytes long; those for non-resident attributes
are longer because they contain information about where to find the attribute on disk.

The standard information field contains the file owner, security information, the timestamps
needed by POSIX, the hard link count, the read-only and archive bits, etc. It is a fixed-length
field and is always present. The file name is variable length in Unicode. In order to make files
with nonMS-DOS names accessible to old 16-bit programs, files can also have an 8 + 3 MS-DOS
name. If the actual file name conforms to the MS-DOS 8 + 3 naming rule, a secondary MS-DOS
name is not used.

382 LOVELY PROFESSIONAL UNIVERSITY