Using and Understanding the RAID Administration Log


Using and Understanding the RAID Administration Log


Being able to read the RAID log produced by the RAID administration and monitoring utilities 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 the RAID Administration program or Netfinity RAID Manager. RAID Administration Program can be obtained from the Configuration Diskette which contains the device drivers under the specific operating system subdirectory. The diskette is available on the IBM website http://www.us.pc.ibm.com/files.html . Search on 'RAID'. The following is an excerpt from a RAID log created by the RAID administration utility:

     RAID Log
     28 January 1997,11:23:38
     Adp 0: Drv at ch 1 bay 5 is replaced by ch 1 bay 2.
     28 January 1997,13:03:30
     Adp 0: Drv at ch 1 bay 2 is defunct.
     28 January 1997,13:03:40
     Adp 0: Drv at ch 1 bay 2 is not auto replaced.

The original configuration was:



The first two lines of the RAID log show that the drive in bay S was marked DDD and auto replaced by the HSP drive in bay 2. At a later point in time after the rebuild to bay 2 was successful, bay 2 was marked DDD. Because there was no HSP drive defined (bay S had been neither physically nor software replaced, so it was still DDD), bay 2 was not auto replaced, so the array remains in the critical state until a replacement drive is added. Using the time stamps on this RAID log, you can tell the exact times the apparent drive failures occurred. You can use this information to rebuild the array properly when multiple DDD drives occur at the same time.

In the current status interpreted by the RAID log, the drive in bay 2 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 drives contain the correct information to rebuild the 'inconsistent' drive assuming no other error has arisen on those drives.

Before you perform any actions on the hardware, use NetFinity, 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 F/W Streaming RAID Adapter/A and SCSI-2 Fast/Wide PCI-Bus RAID Adapter, 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 OFL state. If you are working with systems that have these adapters, do not  perform any operations on the OFL drive until all other DDD drives are changed back to either ONL or HSP. This is because the OFL drive is 'inconsistent' from the rest of the array and requires a rebuild operation. If you do not rebuild the drive, then data will be corrupted.
If you accidentally select an OFL drive to rebuild while other drives in the array besides the HSP are DDD, then the rebuild fails and the OFL drive becomes DDD. In a case such as this, if you have not noted which drive was OFL, then you no longer are able to tell which drive was the original the OFL or 'inconsistent' drive. The best way to ensure data is rebuilt successfully is to perform the following two steps:
  1.  Do not  perform any operations on an OFL drive until all DDD drives have changed  back to either ONL or HSP.
  2.  Write down  which drive is OFL so that you have a note of the 'inconsistent' drive.  This ensures that you will be able to determine the 'inconsistent' drive in case you  inadvertently cause it to go DDD.


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.