Browse Prior Art Database

Mechanism to Distinguish Media Errors from Drive Errors

IP.com Disclosure Number: IPCOM000105635D
Original Publication Date: 1993-Aug-01
Included in the Prior Art Database: 2005-Mar-20
Document File: 2 page(s) / 58K

Publishing Venue

IBM

Related People

Beglin, TW: AUTHOR [+4]

Abstract

Described is a process to isolate Optical Drive failures from media failures. When a failure occurs in an optical drive it is often difficult to determine if the failure was due to the drive or media in a drive. Failures such as Load/Unload and tracking errors fall in these category. A Load/Unload error can be caused by a cartridge out of tolerance or by a drive load/unload mechanism out of tolerance. A tracking error can be caused by a break in the embossed tracks on the disk surface or by the track following mechanism in a drive. A mechanism is needed to determine what caused the error so corrective action can take place.

This text was extracted from an ASCII text file.
This is the abbreviated version, containing approximately 59% of the total text.

Mechanism to Distinguish Media Errors from Drive Errors

      Described is a process to isolate Optical Drive failures from
media failures.  When a failure occurs in an optical drive it is
often difficult to determine if the failure was due to the drive or
media in a drive.  Failures such as Load/Unload and tracking errors
fall in these category.  A Load/Unload error can be caused by a
cartridge out of tolerance or by a drive load/unload mechanism out of
tolerance.  A tracking error can be caused by a break in the embossed
tracks on the disk surface or by the track following mechanism in a
drive.  A mechanism is needed to determine what caused the error so
corrective action can take place.

      A flow diagram as shown in the Figure describes a mechanism to
separate media errors from drive errors.  If a command is sent to a
drive and a failure occurs, the controller retries the command.  If
the failure re-occurs, the controller marks the drive "Failed".
Commands will not be routed to the drive with it marked "Failed".
The controller then sends "Command Failed" status back to the host
with the number of the failed drive.  The host will allow "n"
failures on the same drive before it is declared bad, where "n" is a
programmable number.  This is accomplished by incrementing the "Fail
Counter" at the host each time a command fails with the same drive.
Referring again to the flow diagram, the host then re-issues the
command.  The original command will go to a d...