Using and Understanding the RAID Administration Log

Using and Understanding the RAID Administration Log

Being able to read the RAID log produced by the IPSMON or Netfinity RAID Manager is a very important part of recovering an array when one or more drives are marked DDD. From the RAID log, you can determine in what order drives went DDD, and, if multiple drives are DDD, which one is the 'inconsistent' drive. The RAID log is created by either running IPSMON.EXE or Netfinity Manager. IPSMON.EXE is available on the ServeRAID Supplemental Diskette from the IBM web site Search on 'ServeRAID.' Netfinity Manager is part of ServerGuide which ships with every IBM PC Server and Netfinity Server. The following is an excerpt from a RAID log created by the IPSMON utility:

    09/12/97  09:33:36 INF003:A1C-B-- synchronization started
    09/12/97  09:40:22 INF004:AIC-B-- synchronization completed
    09/12/97  09:41:43 CRT001:AIC3B03 dead drive detected
    09/12/97  09:42:13 INF001:AIC-B-- rebuild started
    09/12/97  09:52:11 INF002:AIC-B-- rebuild completed
    09/12/97  09:55:24 CRT001:AIC3B04 dead drive detected

The original configuration was:

The format is as follows:

    date   time   error   type:Ax Cx Bxx   message

The x following A will be the adapter number, the x following C is the channel, and the xx Ibllowing B is the bay number. error type can be either informational or critical. The message will give a brief description of the RAID event that has occurred.

The first two lines of the RAID log show that a synchronization was started and proceded to complete successfully. At a later point in time, on line 3 of the RAID log, a dead drive is detected on adapter 1, channel 3, bay 3. In this case, since a HSP drive is defined, the rebuild starts automatically. Both the start and finish of the rebuild is logged by the IPSMON monitoring utility. Later on, the drive in bay 4 is marked dead, but no rebuild is started because the HSP drive has already been used.

In the current RAID log, the drive in bay 4 is the 'inconsistent' drive, and you must physically replace it. If more drives are DDD but not listed in the RAID log because the server has trapped (OS/2 or NT) or the volume was dismounted (NetWare), then you need to software replace those drives before replacing the drive in bay 2, because the other drive contain the correct information to rebuild the 'inconsistent' drive.

Before you perform any actions on the hardware, use NetFinity Manager, the RAID administration program, or the RAID configuration program to fill in the attached template at the end of this document with the current status of all the drives, both internal and external. This template provides a three-channel diagram to accommodate all types of IBM RAID adapters.

For the IBM ServeRAID Adapters, if power is lost or another drive is marked DDD during a rebuild operation, the rebuild fails and the drive being rebuilt remains in the RBL state. Because of this, the 'inconsistent' drive remains recognizable.

Back to  Jump to TOP-of-PAGE

Please see the LEGAL  -  Trademark notice.
Feel free - send a Email-NOTE  for any BUG on this page found - Thank you.