Disk drive employing a disk command data structure for tracking a write verify status of a write command

[0001] This application is related to co-pending U.S. patent application Ser. No. 10/080,780 entitled “DISK DRIVE USING ROTATIONAL POSITION OPTIMIZATION ALGORITHM TO FACILITATE WRITE VERIFY OPERATIONS” filed on Feb. 22, 2002, co-pending U.S. patent application Ser. No. 10/286,127 entitled “DISK DRIVE EMPLOYING A MULTI-PHASE ROTATIONAL POSITION OPTIMIZATION (RPO) ALGORITHM” filed on Oct. 31, 2002, co-pending U.S. patent application Ser. No. 10/262,014 entitled “DISK DRIVE EMPLOYING THRESHOLDS FOR CACHE MEMORY ALLOCATION” filed on Sep. 30, 2002, co-pending U.S. patent application Ser. No. 10/262,492 entitled “DISK DRIVE MAINTAINING A CACHE LINK ATTRIBUTE FOR EACH OF A PLURALITY OF ALLOCATION STATES” filed on Sep. 30, 2002, co-pending U.S. patent application Ser. No. 10/286,682 entitled “DISK DRIVE PRE-COMPUTING SEEK PARAMETERS FOR A CONTINUATION TRACK AND A NEXT COMMAND TO FACILITATE CONTINUING A READ-AHEAD OR ABORTING THE READ-AHEAD” filed on Oct. 31, 2002, co-pending U.S. patent application Ser. No. 10/329,166 entitled “DISK DRIVE EXECUTING PART OF A LINKED DISK COMMAND” filed on Dec. 24, 2002, and co-pending U.S. patent application Ser. No. 10/329,161 entitled “DISK DRIVE EXECUTING A MANUFACTURING PROGRAM INTERNALLY BY EXECUTING DISK COMMANDS THROUGH A VECTOR” filed on Dec. 24, 2002, the disclosures of which are incorporated herein by reference.

[0002] 1. Field of the Invention

[0003] The present invention relates to disk drives for computer systems. More particularly, the present invention relates to a disk drive employing a disk command data structure for tracking a write verify status of a write command.

[0004] 2. Description of the Prior Art

[0005] It has been suggested to perform a write verify operation in a disk drive in order to verify the recoverability of recently written data before the write data is purged from the cache buffer. If a write-verify fails, the write command is typically re-executed and re-verified. If the write verify fails a number of times, the marginal data sector is typically relocated.

[0006] The cache buffer typically comprises a valid queue for caching read data read from the disk, a dirty queue for buffering write data to be written to the disk, and an available queue for buffering the write data after it has been written to the disk. The write data in the available queue is typically de-allocated for use by new commands prior to de-allocating read data from the valid queue or flushing write data from the dirty queue. However if a write verify policy is implemented, it is necessary to verify a write command before purging the write data from the cache buffer.

[0007] There is, therefore, a need to track the status of write data in a disk drive so that it is not purged from the cache buffer until passing a write verify operation.

[0008] The present invention may be regarded as a disk drive comprising a disk having a plurality of tracks, wherein each track comprises a plurality of data sectors and each data sector for storing a data block. The disk drive further comprises a head actuated radially over the disk, and a read/write channel for interfacing with the disk through the head. A disk command data structure comprises a write verify counter and a pointer to a plurality of data blocks to be written to a corresponding plurality of target data sectors. A microprocessor within the disk drive executes a write command associated with the disk command data structure by initializing the write verify counter in the disk command data structure, and executes the write command using the disk command data structure by writing the data blocks to the plurality of target data sectors. The microprocessor uses the disk command data structure to perform a write verify operation after executing the write command to verify recoverability of each of the target data sectors. If the write verify operation fails for at least one of the target data sectors, the microprocessor updates the write verify counter in the disk command data structure. If the write verify counter exceeds a threshold, the microprocessor uses the disk command data structure to relocate a data block stored in the at least one of the target data sectors to a spare data sector and resets the write verify counter. If the write verify counter does not exceed the threshold, the microprocessor re-executes the write command and the write verify operation using the updated disk command data structure. If the at least one of the target data sectors passes the re-executed write verify operation, the microprocessor resets the write verify counter and executes the write verify operation for the remaining target data sectors.

[0009] In one embodiment, a dirty queue stores disk command data structures associated with write commands comprising write data to be written to the disk, a write verify queue stores disk command data structures associated with write commands comprising write data to be verified, and an available queue stores disk command data structures associated with write commands comprising write data written to the disk and verified. In one embodiment, the microprocessor inserts a disk command data structure into the write verify queue after executing the associated write command. The microprocessor inserts the disk command data structure into the available queue if the associated write command passes the write verify operation. The microprocessor inserts the disk command data structure back into the dirty queue if the associated write command fails the write verify operation.

[0010] In another embodiment, the disk command data structure further comprises a restart offset for re-executing the write command and the write verify operation starting with the at least one of the target data sectors where the write verify operation failed.

[0011] The present invention may also be regarded as a method of executing a write command associated with a disk command in a disk drive. The disk drive comprises a disk having a plurality of tracks, wherein each track comprising a plurality of data sectors and each data sector for storing a data block. The disk drive further comprises a head actuated radially over the disk, and a read/write channel for interfacing with the disk through the head. A disk command data structure comprises a write verify counter and a pointer to a plurality of data blocks to be written to a corresponding plurality of target data sectors. The write verify counter in the disk command data structure is initialized, and the write command is executed using the disk command data structure by writing the data blocks to the plurality of target data sectors. The disk command data structure is used to perform a write verify operation after executing the write command to verify recoverability of each of the target data sectors. If the write verify operation fails for at least one of the target data sectors, the write verify counter in the disk command data structure is updated. If the write verify counter exceeds a threshold, the disk command data structure is used to relocate a data block stored in the at least one of the target data sectors to a spare data sector and the write verify counter is reset. If the write verify counter does not exceed the threshold, the write command and the write verify operation are re-executed using the updated disk command data structure. If the at least one of the target data sectors passes the re-executed write verify operation, the write verify counter is reset and the write verify operation continues for the remaining target data sectors.

[0026] FIG. 1A shows a disk drive 1 according to an embodiment of the present invention comprising a disk 4 comprising a plurality of tracks 20, wherein each track 20 comprises a plurality of data sectors and each data sector for storing a data block. The disk drive 1 further comprises a head 6 actuated radially over the disk 4, a read/write channel 8 for interfacing with the disk 4 through the head 6, and a microprocessor 10. FIG. 1B shows a flow diagram executed by the microprocessor 10 to perform a write command associated with a disk command data structure. The disk command data structure comprises a write verify counter and a pointer to a plurality of data blocks to be written to a corresponding plurality of target data sectors. At step 3 the microprocessor 10 initializes the write verify counter in the disk command data structure, and at step 5 executes the write command using the disk command data structure by writing the data blocks to the plurality of target data sectors. At step 7 the microprocessor 10 uses the disk command data structure to perform a write verify operation after executing the write command to verify recoverability of each of the target data sectors. If at step 9 the write verify operation fails 11 for at least one of the target data sectors, at step 11 the microprocessor 10 updates the write verify counter in the disk command data structure. If at step 13 the write verify counter exceed a threshold, then at step 15 the microprocessor 10 uses the disk command data structure to relocate a data block stored in the at least one of the target data sectors to a spare data sector and at step 17 resets the write verify counter. If at step 13 the write verify counter does not exceed the threshold, the microprocessor 10 re-executes the write command at step 5 and the write verify operation at step 7 using the updated disk command data structure. If the at least one of the target data sectors passes the re-executed write verify operation at step 9, the microprocessor 10 resets the write verify counter at step 17, and if there are more target data sectors to verify at step 19, continues the write verify operation at step 7.

[0027] In the embodiment of FIG. 1A the disk 4 comprises a plurality of tracks 20, where each track 20 comprises a plurality of data sectors and a plurality of embedded servo sectors 22 recorded at a periodic interval around the circumference of the track 20. The embedded servo sectors 22 are aligned radially to form a plurality of servo wedges. Each embedded servo sector 22 comprises coarse head positioning information (e.g., a track number) processed by the microprocessor 10 to position the head 6 over a target track, and fine head positioning information (e.g., servo bursts) processed by the microprocessor 10 to maintain the head 6 over a centerline of the target track during read and write operations. The disk 4 shown in FIG. 1A comprises radially spaced, concentric tracks 20, however, any suitable track format may be employed including a spiral track format.

[0028] Any suitable disk command data structure may be employed in the embodiments of the present invention. In an embodiment disclosed below with reference to FIG. 3, the disk command data structure comprises a segment descriptor (SD) for storing various parameters associated with each disk command, including a number of optional parameters which may be employed in the embodiments of the present invention.

[0029] FIG. 1C shows a disk drive 2 wherein the microprocessor 10 executes a preemptive multitasking operating system according to an embodiment of the present invention. The preemptive multitasking operating system comprises a plurality of tasks, each task comprising a different priority level. The plurality of tasks comprise a disk task 12, a host task 14, a background task 16, and an execution (exec) task 18. The disk task 12 for processing disk commands by initiating seek operations and configuring parameters of the read/write channel 8. The host task 14 for initiating disk commands in response to host commands received from a host computer. The background task 18 for initiating disk commands to perform background operations including a defect scan of the disk 4. The execution task 16 for arbitrating the disk commands generated by the host task 14 and the background task 18 and for transmitting the arbitrated disk commands to the disk task 12.

[0030] Any suitable microprocessor 10 may be employed in the embodiments of the present invention, including the ARM 966E-S microprocessor manufactured by licensees of ARM Incorporated.

[0031] The priority level of the tasks shown in FIG. 1C is from highest priority on the top (disk task 12) to lowest priority on the bottom (background task 18). Since the host task 14 has a higher priority level than the background task 18, the background task 18 does not interfere with the host interface operation. Further, the execution task 16 gives priority to the disk commands received from the host task 14 over disk commands received from the background task 18. This allows the background task 18 to be interrupted (suspended) when a host command is received from the host computer. After processing the disk command generated by the host task 14, the background task 18 continues the operation it was performing.

[0032] In one embodiment, the execution task 16 executes a rotational position optimization (RPO) algorithm for selecting a next disk command to execute relative to a location of the head 6 with respect to the disk 4. Any suitable RPO algorithm may be employed. In general, an RPO algorithm evaluates the mechanical latency of the disk drive (seek and rotational latencies) in order to select disk commands in an order which minimizes the latency. In one embodiment, the RPO algorithm is implemented in multiple phases relative to non-real-time parameters and real-time parameters. Further details of the embodiment employing a multiple phase RPO algorithm are disclosed in the above reference U.S. patent application entitled “DISK DRIVE EMPLOYING A MULTI-PHASE ROTATIONAL POSITION OPTIMIZATION (RPO) ALGORITHM”.

[0033] FIG. 2 shows an embodiment of the present invention wherein the preemptive multitasking operating system further comprises a plurality of interrupt requests (IRQs). A host bus interface (HBI) interrupt 24 is generated by host interface circuitry communicating with the host computer, wherein the host task 14 receives a host command in response to the host bus interface interrupt 24. A disk formatter (DF) interrupt 26 is generated for configuring disk format parameters associated with a format of the disk, wherein the disk task 12 is notified when the data formatter interrupt 26 finishes processing a current command. A wedge event (WE) interrupt 28 is generated, wherein the disk task 12 is notified when the wedge event interrupt 28 determines a seek operation has completed, and the execution task 16 is notified when the wedge event interrupt 28 determines the head has reached a servo wedge associated with the RPO algorithm. A servo wedge interrupt 30 is generated at each servo wedge 22 (FIG. 1C) for performing time-critical servo processing operations. The servo wedge interrupt 30 may be implemented as a general IRQ, or in an alternative embodiment, the servo wedge interrupt 30 may be implemented as an FIQ having a priority level higher than the IRQs. In this embodiment, the servo wedge FIQ interfaces with the disk task 12 through the wedge event interrupt 28.

In general, the tasks disclosed in FIG. 1C and FIG. 2 perform the following operations:

• • [0034] DISK TASK 12 is responsible mainly for disk formatting operations for read/write commands, such as determining the track format including number and location of defects and configuring the read/write channel circuitry with appropriate parameters. The DISK TASK 12 runs in response to disk formatting hardware (DF IRQ 26) and wedge event interrupt (WE IRQ 28) indicating that a requested seek has completed.
  • [0035] HOST TASK 14 is responsible for receiving commands from the host. It runs in response to commands received from the host bus interface (HBI) hardware via the HBI IRQ 24.
  • [0036] EXECUTION (EXEC) TASK 16 is responsible for arbitrating the disk commands generated by the host task 14 and the background task 18 and for transmitting the arbitrated disk commands to the disk task 12. In one embodiment, the EXEC TASK 16 implements the multi-phase rotational position optimization (RPO) algorithm for selecting the next command to be executed by the DISK TASK 12. The RPO algorithm typically runs after the DISK TASK 12 has emptied a pipeline slot.
  • [0037] BACKGROUND TASK 18 is responsible for implementing background operations. It typically initiates read/write commands not initiated by the host, for example, while performing diagnostic, calibration, or manufacturing procedures.
    There are also a number of event flags associated with each of the tasks:
  • [0038] HOST COMMAND EVENT set by the HBI interrupt 24 service routine when a new command is received from the host.
  • [0039] DISK STOPPED EVENT set by the DF interrupt 26 service routine in connection with a data formatting operation for a current command.
  • [0040] DISK INSERT EVENT set by the EXEC TASK 16 when a next command is inserted into the “next” pipeline slot for the DISK TASK 12. This signals the DISK TASK 12 to pipeline the next command behind the current command being executed.
  • [0041] EXEC DISK COMPLETE EVENT set by the DISK TASK 12 when it moves the next disk command from the “next” pipeline slot into the “current” pipeline slot. This signals the EXEC TASK 16 to execute the RPO algorithm to select the next disk command to execute.
  • [0042] EXEC CALLBACK EVENT set by the DISK TASK 12 after completing the command requested by the EXEC TASK 16.
  • [0043] EXEC INSERT EVENT set by the HOST TASK 14 and BACKGROUND TASK 18 to execute the RPO algorithm based on desired criteria, for example, flushing write commands to free-up cache resources.
  • [0044] EXEC CANCEL EVENT set by the HOST TASK 14 to cancel a command sent to the EXEC TASK 16.
  • [0045] BACKGROUND CALLBACK EVENT set by the EXEC TASK 16 after processing the command requested by the BACKGROUND TASK 18.
  • [0046] BACKGROUND CANCEL EVENT set by the EXEC TASK 16 to cancel the command requested by the BACKGROUND TASK 18.
  • [0047] DISK CANCEL EVENT set by the EXEC TASK 16 to cancel the command in the “next” pipeline slot.
  • [0048] SEEK COMPLETE EVENT set by the wedge event interrupt (WE IRQ 28) to signal the DISK TASK 12 that the requested seek operation has been completed.
  • [0049] WEDGE COUNT VALID EVENT set by the wedge event interrupt (WE IRQ 28) to signal the EXEC TASK 16 that the wedge count is valid and that the second phase of the RPO algorithm may commence.
  • [0050] BACKGROUND INSERT EVENT set by the HOST TASK 14 to start background processing such as diagnostic, calibration, or manufacturing procedures.

[0051] In one embodiment, the background task 18 executes manufacturing procedures during manufacture of the disk drive, such as a defect scan of the disk 4 in order to identify and relocate marginal data sectors to spare data sectors. Further details of this embodiment are disclosed in the above referenced U.S. patent application entitled “A DISK DRIVE EXECUTING A MANUFACTURING PROGRAM INTERNALLY BY EXECUTING DISK COMMANDS THROUGH A VECTOR”.

[0052] FIG. 3 shows a segment descriptor (SD) data structure used to execute disk commands initiated by the host task 14 and the background task 18 according to an embodiment of the present invention. In one embodiment, multiple segment descriptors are linked together to form a linked disk command. The LBA field specifies the starting logical block address (LBA) for the SD, and the COUNT field indicates the number of data sectors associated with the SD. The BUFFER OFFSET field indicates the location of starting LBA in the cache buffer. In one embodiment, thresholds are employed to allocate cache segments from a plurality of segment pools in the cache buffer. More details of this embodiment are disclosed in the above referenced U.S. patent application entitled “DISK DRIVE EMPLOYING THRESHOLDS FOR CACHE MEMORY ALLOCATION”. The CLUSTER RESOURCE BIT MAP specifies which cache segment resources are allocated to the SD (bit 0: 1-sector cache segments, bit 1: 2-sector cache segments, bit 2: 4-sector cache segments, etc.). The CLUSTER RESOURCE BIT MAP facilitates cache memory management as described in more detail in the above referenced U.S. patent application entitled “DISK DRIVE MAINTAINING A CACHE LINK ATTRIBUTE FOR EACH OF A PLURALITY OF ALLOCATION STATES”.

[0053] The NEXT SD INDEX of the SD specifies an index value for a next SD, and the PREV. SD INDEX specifies an index value for a previous SD. These fields facilitate linking SDs together to form linked disk commands in order to improve the RPO algorithm. This embodiment is described in more detail in the above referenced U.S. patent application entitled “DISK DRIVE EXECUTING PART OF A LINKED DISK COMMAND”.

[0054] The STATE of the SD indicates an allocation state for the cache segments allocated to the SD. The allocation states in this embodiment include:

• • [0055] free—an unallocated cache segment;
  • [0056] available—an allocated cache segment storing write data that has been written to the disk;
  • [0057] valid—an allocated cache segment storing cached read data; and
  • [0058] dirty—an allocated cache segment storing write data not yet written to the disk.
    The STATE is used by the execution task 16 to implement various operations, such as allocating/de-allocating cache segments, linking SDs, executing the RPO algorithm, executing a write verify operation, etc.

[0059] The CYLINDER and HEAD of the SD specify the starting cylinder and head for accessing the disk 4 to perform the disk command. These fields are used by the RPO algorithm. The SEEK LATENCY of the SD is also used by the RPO algorithm and specifies the number of servo wedges required to seek the head to the cylinder/head (CH) from the current reference wedge. The ROTATIONAL LATENCY field is used by the RPO algorithm and specifies the number of wedges required to reach the first target data sector after the seek. In one embodiment, these fields are updated by the multi-phase RPO algorithm as disclosed in more detail in the above referenced U.S. patent application entitled “DISK DRIVE EMPLOYING A MULTI-PHASE ROTATIONAL POSITION OPTIMIZATION (RPO) ALGORITHM”.

[0060] The REWRITE/VERIFY COUNT of the SD tracks the number of times a write verify procedure has failed for the SD. If the SD is a write command, after executing the write command the SD is placed in a write verify queue in order to verify the write operation was successful. If the write verify fails, the SD is processed to re-execute the write command. If the number of write verify failures exceeds a threshold, the data block stored in the marginal data sector associated with the SD is relocated to a spare data sector. The RESTART LBA OFFSET of the SD stores the LBA corresponding to the marginal data sector where the write verify failed. This allows the write command and write verify operation to be restarted at the marginal data sector. More details of this embodiment are described below with reference to FIGS. 8A and 8B.

[0061] When the execution task 16 selects an SD to execute according to the RPO algorithm, a command descriptor (CD) data structure shown in FIG. 4 is used to append additional information to the SD. The CDD POINTER of the CD points to a command deviation descriptor (CDD) described below with reference to FIG. 5. The PRE-READ COUNT specifies the number of data sectors to read prior to the first target data sector of the current command, and the POST-READ COUNT specifies the number of data sectors to read after the last target data sector of the current command. The IAD INDEX of the CD is used by the RPO algorithm to setup an intelligent abort descriptor (IAD) for the command. The IAD is used to abort the previous command and begin executing the current command. Further details of this embodiment are disclosed in the above referenced U.S. patent application entitled “DISK DRIVE PRE-COMPUTING SEEK PARAMETERS FOR A CONTINUATION TRACK AND A NEXT COMMAND TO FACILITATE CONTINUING A READ-AHEAD OR ABORTING THE READ-AHEAD”.

[0062] FIG. 5 shows an example of a command deviation descriptor (CDD) according to an embodiment of the present invention which is used to customize configuration parameters for select disk commands. When a CDD is associated with a disk command, the drive operating program initializes the fields of the CDD to default values used during a normal operating mode. A client (e.g., the host, manufacturing or calibration program executed by the background task 18, etc.) may then alter the default parameters to perform a particular operation. By encapsulating the configuration parameters in a CDD data structure and initializing the fields to default values, the disk drive is always properly configured regardless as to how the parameters were configured by the previous disk commands. Further, using well known object oriented techniques, such as inheriting functionality from a base data structure, the CDD can be extended while achieving forward compatibility with existing code and backward compatibility with new code. The CDD shown in FIG. 5 illustrates several suitable configuration parameters, but any suitable configuration parameters may be used in the embodiments of the present invention.

[0063] The FINE TRACK OFFSET of the CDD of FIG. 5 specifies a tracking offset for the head during the disk command (the default tracking offset is zero). The ERROR RECOVERY FLAGS of the CDD enable/disable various features of the error recovery system, such as off-track retries, simple jogging retries, preamp corner shift retries, thermal asperity (TA) detection, firmware error correction code (ECC) processing, finite-impulse-response (FIR) calibration, high-fly write, on-the-fly ECC features, relocations, sync mark, etc. Other configuration parameters in the CDD of FIG. 5 include a seek retry limit, seek time-out limit, file verify limit, wedge offset, wedge length, relocate after retry, and sync mark pattern code. A detailed description of the various configuration parameters shown in FIG. 5 is unnecessary to understand the embodiments of the present invention and has been omitted so as not to obscure the disclosure.

[0064] In one embodiment, the CDD is configured by the background task 18 executing a background program. For example, the defect scan manufacturing program executed by the background task 18 may issue a disk command as well as a configuration command to modify the configuration parameters of the configuration data structure (the CDD). Both commands are issued through a vector implementing a vendor specific command (VSC) as described in more detail in the above referenced U.S. patent application entitled “DISK DRIVE EXECUTING A MANUFACTURING PROGRAM INTERNALLY BY EXECUTING DISK COMMANDS THROUGH A VECTOR”. In another embodiment, a task may modify the configuration parameters of the CDD directly. For example, the disk task 12 may modify the configuration parameters while performing retry error recovery. With each retry operation, the disk task 12 may modify certain configuration parameters, such as certain read/write channel 8 parameters, in an attempt to recover a marginal data sector. Once the marginal data sector is recovered (or relocated), the disk task 12 reverts to the configuration parameters prior to executing the retry error recovery and continues with the current disk command. This embodiment is disclosed in greater detail below with reference to FIG. 10.

[0065] In another example embodiment, the disk task 12 implements a track caching algorithm wherein a number of data blocks stored in the spare data sectors of a track are read and cached in order to expedite access to the data blocks for disk commands that would otherwise access the spare data sectors. Since it is unknown whether some of the data blocks in the spare data sectors will be requested, the disk task 12 modifies the configuration parameters of the configuration data structure so that less stringent error recovery is performed while reading the spare data sectors. This improves performance by skipping unrecoverable spare data sectors rather than perform full error recovery, and only loads the track cache with data blocks from the spare data sectors that are recoverable using the less stringent error recovery. If a data block for a spare data sector is requested that is not loaded into the track cache, the disk task 12 will attempt to recover the spare data sector using full error recovery.

[0066] In one embodiment, a transport descriptor (TD) data structure shown in FIG. 6 is used to pass commands between the tasks. Each task has a first-in first-out (FIFO) command queue for receiving and processing TDs. If needed, an SD and/or CD is attached to the TD to facilitate disk commands as illustrated in FIG. 7. In one embodiment, when the operating system is initialized a number of TDs are allocated and used as needed. The REQ CODE of the TD allows a client (i.e., a first task) to specify a routine to execute in another task. The QUEUED TO DISK FLAG of the TD is set by the media request manager (MRM) in the execution task 16 when the TD has been queued to the disk task 12. This flag enables the MRM to determine when a requested disk command has completed. The PARAMETER of the TD specifies a user routine parameter if needed. The CALL BACK ADDRESS of the TD specifies an address of the routine to execute when the client's request is completed by the task. The NEXT TD points to the next TD in the queue to execute next (if one exists). The SD INDEX of the TD specifies a SD (if one exists), and the CD INDEX specifies a CD (if one exists). The TASK ID of the TD identifies the client (task) that initiated the TD.

[0067] FIG. 8A shows an embodiment of the present invention employing a plurality of state queues, wherein each queue stores a number of SDs having a particular allocation state (free, valid, dirty, etc.) as well as a write verify queue. The write verify queue stores SDs implementing write commands waiting to be verified through a write verify operation. The write verify operation reads recently written data sectors to verify recoverability, and may fail relative to a configurable error recovery threshold. In one embodiment, the write verify operation is performed by the background task 18 when the disk drive is idle (not processing host commands). In an alternative embodiment, the SDs stored in the write verify queue are executed along with other pending commands according to the RPO algorithm. Further details of this embodiment are disclosed in the above referenced U.S. patent application entitled “DISK DRIVE USING ROTATIONAL POSITION OPTIMIZATION ALGORITHM TO FACILITATE WRITE VERIFY OPERATIONS”.

[0068] FIG. 8B is a flow diagram for performing the write verify operation according to an embodiment of the present invention. At step 32 the write verify queue is evaluated to determine whether it contains a pending SD. If so, then at step 34 the SD is selected from the write verify queue. At step 36 the SD is processed to perform the write verify operation for each of the target data sectors in the SD. If at step 38 one of the target data sectors passes the write verify operation, the write verify counter of the SD is reset at step 40. If at step 42 there are no other target data sectors to verify for the SD, then at step 44 the SD is inserted into the available queue indicating the cache memory may be reused for other disk commands. Otherwise the write verify operation continues at step 36 to verify the remaining target data sectors for the SD.

[0069] If the write verify fails at step 38 for at least one of the target data sectors, then at step 46 the write verify counter of the SD is incremented (or in alternative embodiment decremented or otherwise modified). If at step 48 the write verify counter of the SD does not exceed a predetermined threshold, then at step 50 the RESTART LBA OFFSET of the SD is set to the marginal data sector where the write verify failed, and at step 52 the SD is inserted back into the dirty queue so that the write command will be re-executed and re-verified starting with the marginal data sector.

[0070] If at step 48 the write verify counter of the SD exceeds the threshold, then at step 54 the marginal data sector where the write verify failed is relocated. In one embodiment, the marginal data sector is relocated inline by immediately writing the data block to the spare data sector, and in an alternative embodiment, the data block is inserted into a write cache and written to the spare data sector while the disk drive is idle. In one embodiment, an SD is used to write the data blocks stored in the write cache to the spare data sectors, wherein the SD is placed in the dirty queue and write verified according to FIG. 8B. If at step 56 there are no other target data sectors to verify for the SD, then at step 44 the SD is inserted into the available queue indicating the cache memory may be reused for other disk commands. Otherwise, at step 58 the RESTART LBA OFFSET of the SD is set to the data sector following the marginal data sector where the write verify failed, and at step 60 the write verify counter of the SD is reset. At step 62 the SD is inserted back into the write verify queue so that the write verify operation for the SD will continue starting with the data sector following the marginal data sector where the write verify operation failed.

[0071] Encapsulating the write verify counter into the SD simplifies tracking the number of times a write verify fails for a particular write command. The write verify counter remains with the SD as it is transferred between the write verify queue and the dirty queue, and triggers a relocation of a marginal data sector if the write verify counter exceeds the predetermined threshold.

[0072] FIG. 9 shows an overview of the preemptive multitasking operating system, including further details of the execution task 16 and the disk task 12. The high level clients 64 are the originators of disk command requests and include a host computer 66, off-line programs 68 executed by the background task 18 (e.g., a diagnostic or calibration program), and a manufacturing program 70 executed by the background task 18 during a manufacturing process of the disk drive. The execution task 16 comprises application programming interface (API) services for providing a uniform interface regardless as to the task requesting a disk command. For example, vendor specific commands (VSC) may be generated either by an external test system (host computer 66) or the manufacturing program 70. The front-end API services 72 forward the disk commands to a back-end 74 of the execution task 16 implementing a media request manager, a VSC command execution, and the cache and RPO algorithms. Further details of this embodiment are disclosed in the above referenced U.S. patent application entitled “DISK DRIVE EXECUTING A MANUFACTURING PROGRAM INTERNALLY BY EXECUTING DISK COMMANDS THROUGH A VECTOR”.

[0073] The execution task 16 communicates with the disk task 12 using TDs described above with reference to FIG. 6. The disk task 12 comprises a top level disk task 76 which decodes the TDs, performs limited processing such as performance optimized read and write operations (or cache requests), and distributes other processing to one or more of a plurality of disk task modules including a file read/write module 78, an auto-relocation module 80, a check disk module 82, an error recovery module 84, and a relocation read/write module 86. The file read/write module 78 handles reading and writing system files located in a reserved area of the disk 4 or in semiconductor memory (e.g., FLASH). The auto-relocation module 80 relocates data blocks from marginal data sectors to spare data sectors. In one embodiment, the auto-relocation module 80 relocates a data block for a marginal data sector detected during the write verify operation described above with reference to FIGS. 8A–8B. In an alternative embodiment, a relocation request may be issued by a client (e.g., host computer or manufacturing program executed internally) through a VSC operation. The check disk module 82 contains the physical low level disk access routines, including to centralize the error recovery algorithm. The error recovery module 84 is invoked by the check disk module 82 and implements various error recovery techniques, including retry error recovery and firmware error correction code (ECC) processing (e.g., erasure pointer or Turbo code processing) when an error is detected while accessing the disk. In an alternative embodiment described below with reference to FIG. 11, the firmware ECC processing is implemented by a separate error recovery task 88. The relocation read/write module 86 is invoked by the check disk module 82 when a data block stored in a spare data sector needs to be accessed. As described above, in one embodiment the data blocks read from the spare data sectors of a track are cached in a track cache to expedite subsequent disk commands.

[0074] In the embodiment of FIG. 9, the various modules in the disk task 12 communicate with each other using a disk activity block (DAB) data structure, an example for which is shown in FIG. 10. The PARENT DAB field points to a parent DAB which generated the current DAB for the current disk command. This embodiment facilitates performing disk commands using custom configuration parameters through a custom CDD. For example, the disk task 12 may modify the configuration parameters while performing retry error recovery. To facilitate modifying the configuration parameters, a new DAB is generated for the current disk command and the configuration parameters in the CDD of the current DAB (the parent DAB) are copied into the CDD for the new DAB. The configuration parameters in the CDD of the new DAB are then modified with appropriate values (e.g., adjusting the fine tracking offset) and the current disk command re-executed using the custom CDD. Once the marginal data sector is recovered (or relocated), the parent DAB is re-assigned to the current disk command so that the current disk command continues execution using the configuration parameters in the original CDD.

[0075] The CDD POINTER of the DAB in FIG. 10 points to the CDD data structure described above with reference to FIG. 5. The NEXT TRACK LBA of the DAB specifies the first LBA of the next track. The COUNT of the DAB specifies the total number of data blocks for the current request. The REMAINING COUNT of the DAB specifies the remaining number data blocks for the current request to be processed. The SERVO RETRY COUNTER of the DAB indicates the number of times the servo has failed for the current data sector. The READ RETRY COUNTER of the DAB indicates the number of times the read retry has failed for the current data sector, and the WRITE RETRY COUNTER indicates the number of times the write retry has failed for the current data sector. The SD POINTER of the DAB points to the SD data structure described above with reference to FIG. 3, and the CD POINTER points to the CD data structure described above with reference to FIG. 4. The ZONE of the DAB identifies the ZONE for the next LBA to process, and the CHW identifies the cylinder/head/wedge for the next LBA to process.

[0076] Any suitable number of tasks may be employed in the embodiments of the present invention. In addition, certain operations performed by existing tasks may be implemented in a separate task. FIG. 11 shows an embodiment of the present invention comprising a separate error recovery task 88 for implementing firmware error recovery algorithms. In one embodiment, some or all of the firmware ECC processing performed by the error recovery module 84 of the disk task 12 (FIG. 9) is moved to the error recovery task 88. In another embodiment, the error recovery task 88 performs firmware ECC processing, such as using erasure pointers or performing multiple passes of a Turbo code, concurrent with the disk task 12 performing retry error recovery. In the embodiment shown in FIG. 11, the error recovery task 88 is executed at the lowest priority level, but it may be assigned any suitable priority level such as above the background task 18. FIG. 12 shows an embodiment of the present invention comprising a separate RPO task 90 rather than implement the RPO algorithm in the execution task 16. The RPO task 90 is assigned a priority level higher than the background task 18, but it may be assigned any suitable priority level, such as above the execution task 16 or the host task 14.