Please consider a donation to the Higher Intellect project. See or the Donate to Higher Intellect page for more info.

Disk Initialization Manager

From Higher Intellect Vintage Wiki
Jump to navigation Jump to search

The Disk Initialization Manager is the part of the Macintosh Operating System that manages the process of initializing disks. This package accepts requests to initialize a disk and translates them into control calls for the corresponding disk driver. The Disk Initialization Manager itself does not perform the low-level formatting or verification of the disk; instead, it simply manages the communication between the software requesting that a particular disk be initialized and the appropriate disk driver.

Usually, the Finder or the Standard File Package calls the Disk Initialization Manager when the user inserts an uninitialized disk. Occasionally the user will insert a disk when your application is frontmost. At that time, the Operating System generates a disk-inserted event. If your application has not masked out such events, it receives an event record for that event when it makes an event call and no events with higher priority are pending. You then need to determine whether the inserted disk is valid (as indicated by a value in the event record). If the disk is not valid, you should call the Disk Initialization Manager to allow the user to initialize the disk or, if desired, eject it.

If your application masks out disk-inserted events, the event stays in the event queue until your application calls the Standard File Package (which automatically processes disk-inserted events) or until the current application can handle disk-inserted events. In general, it’s best not to mask out disk-inserted events and to handle them as described later in this chapter; otherwise, the user is likely to become confused when, after inserting an uninitialized or damaged disk, no disk icon appears on the desktop and no standard disk initialization dialog box appears. (Icons of initialized and undamaged disks always appear on the desktop, even if the current application ignores disk-inserted events.)

Disk Initialization

Disk initialization is the process of making a disk usable by the Macintosh Operating System. When shipped, most floppy disks are uninitialized because different operating systems have different initialization requirements. On Macintosh computers, disk initialization consists of three independent steps:

  • disk formatting
  • disk verification
  • disk zeroing

All three steps must be performed successfully before the disk is considered initialized (or valid). You can use a single Disk Initialization Manager function, DIBadMount, to perform all three operations in sequence, or you can perform any one of them by calling a corresponding low-level function (either DIFormat, DIVerify, or DIZero). In general, your application should use the standard user interface described in the following section to initialize a disk.

The first step in the initialization process is disk formatting. Formatting a disk consists of writing special information onto a disk so that the disk driver can read from and write to the disk. This involves dividing the total usable space into sectors and tracks.

The second step in the disk-initialization process is disk verification. Verifying a disk consists of reading every bit on the disk to ensure that the disk has been formatted correctly and contains no bad blocks. If an error occurs during the reading of any single bit, the verification is considered unsuccessful.

The third and final step in the disk-initialization process is disk zeroing. Zeroing a disk consists of creating on the disk the data structures and files necessary for the disk to be recognized as a hierarchical file system (HFS) volume. In particular, zeroing a disk places a master directory block (MDB), a volume bitmap, and a catalog file in appropriate locations on the disk. (For information on the locations and sizes of these items, see the description of the organization of data in a volume in the chapter “File Manager” in this book.) The volume bitmap and catalog file are set up to represent a volume containing no user files. As a result, zeroing a disk makes any files previously located on the disk inaccessible.

Beginning in system software version 7.0, zeroing a disk also causes the Disk Initialization Manager to attempt to remove any bad blocks (as identified during the disk-verification process) from the pool of available blocks on the disk. See “Bad Block Sparing” on page 5-7 for a description of this capability.

Bad Block Sparing

Beginning with system software version 7.0, the Disk Initialization Manager tries to initialize a disk even if it contains some bad blocks; this feature is called bad block sparing. Without bad block sparing, the Disk Initialization Manager considers a disk unusable even if just one block is bad. With bad block sparing, however, the Disk Initialization Manager attempts to work around the bad block by removing it from the pool of available free blocks. This prevents the File Manager from allocating the block to a file. Except in cases (described later) involving critical blocks on a disk, the Disk Initialization Manager can usually initialize a disk that would previously have been rejected as invalid. This section describes the operation of bad block sparing.

The bad block sparing occurs during the disk-zeroing phase of disk initialization. As a result, sparing occurs only when you call DIZero or DIBadMount (which internally calls DIZero), never when you call DIFormat or DIVerify. The only visible sign of the sparing process is an additional dialog box that contains the message “Re-Verifying Disk.”

Disks without bad blocks are initialized exactly as in previous versions of system soft- ware. The sparing algorithm is invoked only if the disk verification fails during a call to the DIBadMount function or if the DIZero function encounters bad blocks during its zeroing. The sparing algorithm proceeds by making a second pass over the disk, writing and then reading back a test pattern. This testing is done a single track at a time. If any retries or errors occur during this test, all the sectors in the track are deemed bad.

If more than 25 percent of the disk is found to contain bad blocks, if the I/O errors appear to be due to hardware failure rather than media failure, or if certain critical sectors (described later) are bad, then the initialization fails just as it would have without the bad block sparing. Otherwise, the HFS volume structure is written to the disk. After the volume structure has been written, the Disk Initialization Manager performs several further operations during bad block sparing.

1. It sets the appropriate bits in the volume bitmap to indicate that the bad blocks are allocated to a file.

2. It creates file extent descriptors for the bad blocks and inserts them into the volume extents B*-tree so that the free-space scavenging that occurs at volume mount time (or that is done by disk utilities such as Disk First Aid) does not reintroduce the bad blocks into the volume bitmap. A special file ID (5) is used for these extents.

3. It sets bit 9 in the drAtrb field of the master directory block to indicate that bad blocks in the disk have been spared.

4. On 800K floppy disks only, it reduces the number of allocation blocks on the disk by 1 (from 1594 to 1593), to prevent previous versions of the Finder from doing disk-to-disk copies physically (that is, sector by sector). This copying operation would fail during an attempt to copy the bad blocks. The Finder does physical copies as an optimization only on disks containing exactly 1594 allocation blocks.

The critical sectors (those that must be good even on a spared disk) include the boot blocks, the master directory block and the spare master directory block, the volume bitmap, and the initial extents for the catalog and extents B*-tree files of the volume.

Notice that the bad block sparing algorithm does not create any new entries in the volume’s catalog file. In other words, steps 1 and 2 of the algorithm trick the File Manager into thinking that the bad blocks have been allocated to some file, although no file is actually created to contain those blocks. For this reason, directory enumerations and file-by-file copies can proceed as they would have without bad block sparing. (If a file were created for the bad blocks, that file would need a parent directory; in that case, reading the catalog file to determine how many files that directory contains would produce erroneous results.)

See Also