Browse Prior Art Database

Detection of Lost Command in Command Queuing Environment

IP.com Disclosure Number: IPCOM000109727D
Original Publication Date: 1992-Sep-01
Included in the Prior Art Database: 2005-Mar-24
Document File: 2 page(s) / 89K

Publishing Venue

IBM

Related People

Schwendiman, CA: AUTHOR [+2]

Abstract

This article describes a method for implementing a timeout scheme for I/O requests to a disk device where that device might have multiple I/O requests outstanding simultaneously. This method assumes that the disk device driver implements a seek optimization (or elevator) algorithm.

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

Detection of Lost Command in Command Queuing Environment

       This article describes a method for implementing a
timeout scheme for I/O requests to a disk device where that device
might have multiple I/O requests outstanding simultaneously.  This
method assumes that the disk device driver implements a seek
optimization (or elevator) algorithm.

      Intelligent peripheral devices, such as today's disk devices,
tend to complicate host error recovery.  One such complication is the
handling of command timeouts to a device that supports command
queuing. Such devices also have the ability to reorder the execution
of those commands to optimize performance.  This capability makes it
difficult for host system device drivers to determine that a
particular command must be hung (timed out).  The device driver
typically keeps some sort of system timer running with an appropriate
timeout value for the completion of one command.  As long as the
driver continues to receive completion notifications for commands, it
assumes everything is operating normally, resetting the timer upon
completion of each command.  The problem with this scheme is that if
the system is keeping a constant load on the device driver, and in
turn, the device driver is keeping the device queue full, it is
possible for hung commands to be lost.

      Some of the existing solutions include:
      1)   Providing support at the hardware level (disk drive) to
allow the device driver to query the progress of a certain command.
This solution is very hardware-dependent and is therefore not
acceptable in a high connectivity environment such as SCSI (Small
Computer System Interface).  It also requires the device driver to
instigate the query of the command which requires the parsing of a
command map upon every command completion.
      2)   Maintaining a list of all outstanding commands, and upon
the completion of each command, parsing the list to determine if any
commands have been preempted some unacceptable number of times.  This
method increases critical path length for normal operation in a
performance critical subsystem...