Disk array system, controller, and method for verifying command data written to disk drives

[0002] The present invention relates generally to mass data storage systems, and more specifically, relates to methods for verifying the integrity of command data sent to an ATA (Advanced Technology Attachment) or other storage device.

[0003] Host computers use peripheral data storage devices such as hard disk drives to store large amounts of data. The host computer typically communicates with the storage device over a cable, such as a ribbon cable, according to a particular interface. In the personal computer (PC) industry, the most common disk drive interface is currently the ATA (Advanced Technology Attachment) interface, also referred to as the IDE (Integrated Drive Electronics) interface. Several versions of the ATA interface have been developed over time, including ATA-1, ATA-2, ATA-3, ATA-4 (also known as Ultra DMA-33, in which “DMA” stands for Direct Memory Access), ATA-5 (also known as Ultra DMA-66), and Ultra DMA-6. Another common disk drive interface is SCSI (Small Computer Systems Interface).

[0004] One problem with mass storage systems is that data transmitted over the cable between the host computer and the storage device can be corrupted. Such corruption may occur, for example, as the result of radio frequency (RF) emissions from nearby components or appliances. To address this problem, existing interfaces commonly use parity or other error detection schemes to check for transmission errors. Some interfaces, however, such as the ATA interface, do not check for errors in the transmission of commands transmitted from the host computer to the storage device. As a result, a corrupted command may be executed by the storage device, potentially resulting in an unrecoverable loss of data.

[0005] The present invention addresses this and other problems related to the integrity of command data transmitted over a cable.

[0006] The present invention overcomes the above problems by implementing a process for verifying the integrity of command data written to a disk drive before such command data is used to execute a command. The process is implemented by a controller which controls the disk drive over a cable or other connector. The controller may be implemented within automated circuitry and/or firmware.

[0007] In accordance with the invention, the controller initially writes command data to the disk drive, and then reads back and verifies at least a portion of this data prior to initiating execution of the command. In ATA implementations, the command data read back from the drive and checked corresponds to selected registers and bits (preferably registers 2, 3, 4 and 5 in their entirety, and bits 3:0 of register 6) of the ATA command register block. If this command data is consistent with the command data written to the drive, the controller initiates execution of the command (by writing to register 7 in ATA implementations). If, on the other hand, the read-back command data is inconsistent with the written-out command data, the controller enters into an error state that prevents the potentially corrupt command data from being used by the drive. To further protect against transmission errors, the controller may, following execution of the command, read a status code from the drive more than once to reduce the likelihood of misread status information.

[0008] In one embodiment, the invention is incorporated into each of a set of automated ATA controllers of a disk array controller. Each such controller implements the host side of the ATA interface within automated circuitry. Preferably, each automated controller includes a command buffer for storing multiple command blocks, so that a new command block can be dispatched to the disk drive immediately following completion of a current command block.

[0009] The invention may also be used with interfaces other than the ATA interface, and may be used with peripheral storage devices other than hard disk drives.

[0010] FIG. 1 illustrates a host computer system in which the invention may be embodied.

[0011] FIG. 2 is a flow diagram that illustrates the verification of command data written to a data storage device in accordance with one embodiment of the invention.

[0012] FIG. 3 illustrates a disk array controller in which the invention may be embodied.

[0013] A preferred embodiment will now be described in which the invention is used to verify the integrity of command data transmitted to an ATA disk drive, which is one type of device that currently does not verify the integrity of command data it receives. As will be recognized by those skilled in the art, the invention can also be used with other devices and device interfaces that do not verify the integrity of command data written to the device. In addition, the invention can be used to supplement the error detection schemes used by interfaces such as the SCSI interface, and can be used with other types of mass storage devices such as optical drives.

[0014] FIG. 1 illustrates a host computer 100 in which the present invention may be embodied. The host computer may, for example, be a desktop PC, a server, or a network-attached storage box. The host computer includes an ATA disk drive 120 which is controlled by an external controller 130. The ATA disk drive may be a standalone storage device, or may be part of a disk drive array. As will be recognized by those skilled in the art, the invention is also applicable to serial ATA devices, and to PCMCIA (Personal Computer Memory Card International Association) and other FLASH memory cards that emulate hard disk drives.

[0015] The controller 130 may be implemented through firmware (e.g., the conventional Basic Input/Output System or “BIOS” firmware executed by host computer's microprocessor or microcontroller 110, referred to herein generally as “processor” 110), or may be implemented within automated circuitry. (As used herein, the term “automated” refers to circuitry that operates without fetching and executing sequences of macro-instructions.) In one embodiment (shown in FIG. 3), the controller is a special integrated circuit that implements the host side of the ATA interface within automated circuitry. Regardless of the type of controller used (automated hardware versus firmware), the controller communicates with the disk drive over a cable (such as a standard ATA ribbon cable) or other connector 140.

[0016] As depicted in FIG. 1, the ATA disk drive 120 includes a standard command register block 150 consisting of eight registers (0-7), also known generally as the task file registers. These registers are used to receive commands from, and to return status information to, the controller 130. The data written to the command register block is commonly referred to as a “command block” or “task file.”

[0017] Conventionally, the host computer 100 initiates a disk operation by initially writing the LBA (logical block address) and other command data to registers 1-6 (plus register 0 for Programmed Input/Output or “PIO” operations), and then writing a corresponding command opcode to the command register (register 7). Once the command register has been loaded, the ATA disk drive 120 executes the command specified by the task file. The controller may thereafter monitor the status of the command's execution, and determine whether the command completes successfully, by reading the appropriate status bits of the command register block 150.

[0018] During this prior art process, various types of errors can occur as the result of undetected transmission errors over the cable 140. For example, the disk drive may report successful completion of the command even though one or more bits (e.g., bits of the LBA) were modified. Further, the host computer may misread an error or status code reported by the disk drive. These and other types of transmission-related errors can result in the unrecoverable loss of data.

[0019] In accordance with the invention, the likelihood of such data loss is significantly reduced by having the controller 130 read back and verify appropriate portions of the command data written to the disk drive before the command is executed. If the command data read from the disk drive is consistent with the written-out command data, the controller loads the command register to initiate execution of the command; otherwise, the controller 130 initiates an appropriate error handling routine and/or corrects the corrupted information and retries the operation. To further reduce the likelihood of data loss, the controller also preferably reads the status bits associated with the command's execution at least twice. The additional read or reads of the status bits reduces the chance of a status code being misread.

[0020] FIG. 2 illustrates this process in further detail. As noted above, the operations shown in FIG. 2 may be implemented within automated hardware or through firmware (or a combination of both). The use of automated hardware has the advantage of allowing these operations to be performed more rapidly. As depicted by block 200, the controller 130 initially writes all applicable registers of the command register block 150 (or at least those that are read-back and verified) with the exception of the command register (register 7). The specific registers loaded during this stage depend upon the type of disk operation being performed, but typically include registers 1-6. The controller maintains a copy of the written-out command data (referred to generally as “control information” in FIG. 2) for subsequent comparison to the read-back command data. The controller then reads back at least some of the command data (control information) from these registers (block 210), and compares this data to the buffered copy of the command data (block 220) for consistency. Task file bits which do not necessarily reflect the written command data are ignored during this comparison in block 220. Preferably, the portions of the command register block that are checked in block 220 are registers 2, 3, 4, and 5 in their entirety (bits 7:0) and bits 3:0 of register 6; registers 0, 1, and 7, and bits 7:4 of register 6, are ignored.

[0021] If the relevant command data read back from the drive is inconsistent with the written-out command data, an error state is entered (block 280) which prevents the potentially corrupt command data from being used by the drive. In the illustrated embodiment, the controller 120 interrupts the host processor 110 in this situation, although the controller could alternatively retry the operation one or more times before generating the interrupt. Upon being interrupted, the host processor may read an error register to determine the type of error that occurred, and then invoke an appropriate error handler. If no errors are detected during the comparison, the controller loads the command register to start the operation (block 230).

[0022] As depicted by blocks 240-270, after waiting for the transfer to occur, the controller 130 preferably reads and verifies the status register twice to determine whether the operation completed successfully. In particular, the controller reads and checks bits 0 and 7 (“error” and “busy”) twice to confirm that they are both clear (zero). If, on either read operation (blocks 240 or 260), this criterion (both bits clear) is not satisfied, the controller enters into an appropriate error state (block 280) and interrupts the host processor 110. In other embodiments of the invention, the status recheck operation 260 may be omitted.

[0023] As mentioned above, the controller 130 could alternatively be designed to retry the command one or more times before interrupting the processor 110. For example, upon detecting an inconsistency between the written-out and read-back command data, the controller could reload and then recheck registers 1-6, and proceed with command execution if no error is detected.

[0024] FIG. 3 illustrates one particular application for the invention. In this embodiment, the host computer 100 hosts a disk array controller 300 that controls multiple ATA disk drives 120. The disk array controller 300, may, for example, be in the form of a card that plugs into a standard PCI (Peripheral Component Interconnect) slot. In embodiments in which the host computer 100 is a network-attached storage box, the array controller 300 may be implemented within a chip set on the host computer's main board. The disk array controller may be constructed and may operate as generally described in U.S. Pat. No. 6,098,114, the disclosure of which is hereby incorporated herein by reference.

[0025] Each ATA disk drive 120 in FIG. 3 is controlled by a respective automated controller 130 over an ATA cable or other connector 140. The automated controllers 130 may be implemented, for example, within ASIC (application-specific integrated circuit) devices. Each automated controller includes a command/transfer or “protocol” engine 320 which implements the host side of the ATA interface within state machine logic. The command/transfer engines 320 also include state machine logic for implementing the data protection process shown in FIG. 2. As described in the above-referenced patent and depicted in FIG. 3, each command/transfer engine preferably includes a command buffer 330 that stores up to two command blocks (task files) at a time. This feature allows a new command block to be written to the controller 130 while another command block is being executed, so that the new command block can be processed immediately following completion of the current command block. The automated controllers also include respective FIFOs (first-in-first-out buffers), 322 for transferring input/output (I/O) data to and from the disk drives 120.

[0026] In operation, a device driver executed by the host's main processor 338 sends I/O requests to the array controller 300 via a PCI bus 342 and an automated array coprocessor 380. A firmware control program executed by the microcontroller 110 translates the I/O request into a number of command blocks to be executed by the ATA drives, and stores these command blocks together with associated control information in drive-specific command queues in RAM (random access memory) 398. The number of disk drives invoked by the I/O request, and the identities of such drives, depend upon the particular type RAID (redundant array of inexpensive disks) or other disk array configuration implemented by the control program.

[0027] When an automated controller 130 is ready to receive a new command block (i.e., has an empty slot in its command buffer 330), that controller requests a new command block from the microcontroller 110 over a local control bus 386 (e.g., by interrupting the microcontroller). The microcontroller 110 responds to this request by dispatching a command block from the drive's command queue over the local control bus. During execution of the command block by a disk drive 120, the associated controller 130 arbitrates for control of a packet-switched bus 390, which is used to handle all transfers of I/O data between the drives and system memory 340 (and between the drives and a buffer 394). Preferably, the automated array coprocessor 380 grants timeslots on the packet-switched bus using a round robin type arbitration protocol. If a controller 130 detects an error as a result of the command read-back or status re-check operations of FIG. 2, that controller interrupts and passes an error code to the microcontroller 110. The microcontroller may then execute an appropriate error handler before retrying the operation.

[0028] Although this invention has been described in terms of certain preferred embodiments, other embodiments that are apparent to those of ordinary skill in the art are also within the scope of this invention. Accordingly, the scope of the invention is defined only by reference to the appended claims.