logo

Manual Pages


Table of Contents

NAME

fcdiag - Diagnostic to assist in determining source of loop instability

SYNOPSIS

fctest [ -v ] [ -t minutes ] < adapter >

DESCRIPTION

Loop instability can be caused by a number of loop component failures; cables, LRC cards, shelves or drives. Making use of the ability to bypass and unbypass drives on a loop, fcdiag implements a "binary search" algorithm to find a drive responsible for loop instability. Finding any other component failures is beyond the scope of this diagnostic.

The diagnostic is only available in maintenance mode.

If the -v option is specified, the output is verbose.

By default, the running time is about 2 minutes per step of the binary search. However, if the -t minutes option is provided, each step will run for minutes minutes instead.

The diagnostic will be run on the loop corresponding to the adapter argument.

THEORY OF OPERATIONS

fcdiag works by using a combination of binary search techniques and the newly implemented LPE and LPB primitives which allow one to bypass and unbypass drives, i.e. make them disappear and reappear.

Caveats:

(1) The loop must be closed, due to hardware limitations of the QLogic implementation of LPE and LPB.

(2) Eurologic shelves don't retime, so a drive must be present in every loop segment, where a loop segment is defined as a consecutive sequence of loop IDs. The diagnostic attempts to verify that no segments are empty, but its algorithms are not fool-proof.

(3) It is assumed that only drives are responsible for loop instability, and there is only *one* failing drive. In light of the possibility that there may be more than one flakey drive, a "linear search" option will be added; trading off speed vs. coverage.

During operation, fcdiag performs the following:

(1) Determine two "stable" configs, where a stable config is defined as one which meets the requirement in Caveats (2).

(2) Test [testing is done using a variant of fctest] the two stable configs. If one is found to be unstable, use the other as the "benchmark dead config". If neither is stable, bail .... test is inconclusive.

(3) Starting with the "benchmark dead config", add/remove drives implementing a binary search. At every "step" if a test shows instability, verify that the "other half" of the binary search step shows loop stability. If not, bail ..... test is inconclusive.

(4) Test stops when either (a) no loop instability has been found and all search paths have been exhausted, or (b) the search has exhausted an unstable search path and narrowed down to one drive .... that's our bad boy.


Table of Contents