Legacy Document

Inside Macintosh: Files /

Chapter 5 - Disk Initialization Manager / About the Disk Initialization Manager

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.

WARNING

Applications that manipulate disks using File Manager routines are unaffected by bad block sparing. Software that accesses blocks directly from the disk or that makes assumptions about the physical blocks on a disk (such as a disk scavenger, recovery, or backup utility) is likely to fail or cause a loss of data on disks containing spared blocks.

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 software. 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.)

Note

The bad block sparing capability described in this section applies
only during disk initialization. The Operating System cannot
correct problems that occur after a disk has been initialized
(except by reinitializing the disk).