Legacy Document

Inside Macintosh: Files /

Chapter 2 - File Manager / Data Organization on Volumes

Extents Overflow Files

The File Manager keeps track of which allocation blocks belong to a file by maintaining a list of contiguous disk segments that belong to that file, in the appropriate order. When the list of disk segments gets too large, some of those segments (or extents) are stored on disk in a file called the extents overflow file.

The structure of an extents overflow file is relatively simple compared to that of a catalog file. The function of the extents overflow file is to store those file extents that are not contained in the MDB or VCB (in the case of the catalog and extents overflow files themselves) or in an FCB (in the case of all other files). Because the first three file extents are always maintained in memory (in a VCB or an FCB), the File Manager needs to read the extents overflow file only to retrieve any file extents beyond the first three; if a file has at most three extents, the File Manager never needs to read the disk to find the locations of the file's blocks. (This is one good reason to promote file block contiguity.)

An extent is a contiguous range of allocation blocks that have been allocated to some file. You can represent the structure of an extent using an extent descriptor, defined by the ExtDescriptor data type.

TYPE ExtDescriptor      =        {extent descriptor}
RECORD
   xdrStABN:      Integer;       {first allocation block}
   xdrNumABlks:   Integer;       {number of allocation blocks}
END;

An extent descriptor record consists of the first allocation block of the extent, followed by the number of allocation blocks in that extent. The File Manager prefers to access extent descriptors in groups of three; to do so, it uses the extent data record, defined by the ExtDataRec data type.

TYPE
   ExtDataRec: ARRAY[1..3] OF ExtDescriptor;{extent data record}

Recall that the drCTExtRec and drXTExtRec fields of the MDB are of type ExtDataRec (see "Master Directory Blocks," earlier in this chapter), as is the fcbExtRec field of an FCB (see "File Control Blocks" beginning on page 2-81). Also,
the records in the leaf nodes of the extents overflow file are extent data records. For
this reason, the extents overflow file is much simpler than the catalog file: the data in
a leaf node of an extents overflow file always consists of a single kind of record,
instead of the four kinds of records found in a catalog file.

The other main difference between a catalog B*-tree and an extents overflow B*-tree concerns the format of the key. You can describe an extent record key with the ExtKeyRec data type.

TYPE ExtKeyRec    =              {extent key record}
RECORD
   xkrKeyLen:     SignedByte;    {key length}
   xkrFkType:     SignedByte;    {fork type}
   xkrFNum:       LongInt;       {file number}
   xkrFABN:       Integer;       {starting file allocation block}
END;

Field Description

xkrKeyLen

The length (in bytes) of the rest of the key. In the current implementation, this field always contains the value 7.

xkrFkType

The type of file fork. This field contains $00 if the file is a data fork and $FF if the file is a resource fork.

xkrFNum

The file ID of the file.

xkrFABN

The starting file allocation block number. In the list of the allocation blocks belonging to this file, this number is the index of the first allocation block of the first extent descriptor of the extent record.

Note

Disks initialized using the enhanced Disk Initialization Manager introduced in system software version 7.0 might contain extent records for some blocks that do not belong to any actual file in the file system. These extent records have a file ID set to 5, indicating that the extent contains a bad block. See the chapter "Disk Initialization Manager" in this book for details on bad block sparing.