topic Re: VA7410 non redundant disk access in Disk Enclosures

VA7410 non redundant disk access

jerry1 — Wed, 16 Sep 2009 18:25:54 GMT

I am having the same problem as a post with
same subject: VA7410 non redundant disk access.

It started as a disk failure.

Sep 1 21:15:55 dbsvr1 syslog: CVSDM; MAJOR WARNING Event Code=204; Description=
One or more disks have failed.; ; Hardware Address=1/0/12/0/0.2.19.0.0.2.2; FRU
Location=JB2/D4; Vendor ID=HP 36.4G; Model ID=ST336607FC; Product S/N=3JA6NMNX;
Latest information on this event at http://docs.hp.com/hpux/content/hardware/ems
/RemoteMonitor.htm#204

And then another disk failed two weeks later.

Sep 13 07:08:01 dbsvr1 syslog: CVSDM; MAJOR WARNING Event Code=204; Description=
One or more disks have failed.; ; Hardware Address=1/0/12/0/0.2.19.0.0.2.2; FRU
Location=JA0/D12; Vendor ID=HP 36.4G; Model ID=ST336607FC; Product S/N=3JA1FNJY;
Latest information on this event at http://docs.hp.com/hpux/content/hardware/em
s/RemoteMonitor.htm#204

The Address listed is not being used with
any volume group so I was not in a hurry
to replace the drives.

I replaced both drives and now I still get
the warning message "non redundant disk access"

All lights are green on the back and front.
All looks okay in Commandview except for
the Warning. But nothing points to what is
wrong or how to reset the warning.

I have the latest firmware on the controller.

Re: VA7410 non redundant disk access

TTr — Wed, 16 Sep 2009 18:50:39 GMT

Check the status of the VA with commandview. "non redundant disk access" menas that there is an array group that is running without disk redundancy. If one more disk fails in that array, there will be loss of data.
Autoraid is not easy to explain because it does not rely on *whole* physical disks for redundancy, but consider the following two examples:
Array A is set up as raid5 and has 4 disks in it and one disk has failed.
Array B is setup as raid10 with six disks in it and three disks have failed, one failed disk in each mirrored pair.
In both examples the arrays are still up and running and are serving data but they have no redundancy. If one more disk fails in either array there will be loss of data.
Something similar has happened in autoraid. Check the status, maybe the disks that you replaced did not get rebuilt.

Re: VA7410 non redundant disk access

jerry1 — Wed, 16 Sep 2009 19:08:00 GMT

The only thing I see in Commandview is
the Warning message.

Re: VA7410 non redundant disk access

TTr — Wed, 16 Sep 2009 21:15:29 GMT

Did you get a complete listing that shows the status of each component? This listing shows everything, disk spindles, LUNs , memory, controllers etc. I think the command is "armdsp -a". Log into the console if you have to.

Re: VA7410 non redundant disk access

Torsten. — Thu, 17 Sep 2009 05:16:44 GMT

Could you please post

# armdsp -a

# armdsp -t

Re: VA7410 non redundant disk access

jerry1 — Thu, 17 Sep 2009 14:33:56 GMT

The problem is fixed. I hope.

I went down to check the VA and found
a yellow light on one of the disks. Not
one of the two disks that were replaced.
This did not show up in the CommandView
IE web browser or in the armdsp outputs
for -t -a or -c. I reset the disk and
it went to green. I refreshed the IE
and the warning went away. CVSDM logged
the correction in syslog:

CVSDM; CORRECTED: Event Code=238; Description=CO
RRECTED: Non redundant disk access.; ; This previously occuring event has
been corrected.

It looked like from past logs that the
rebuild failed and put the VA in a
non redundant disk access because of the
one drive. Based on the logged message from
before:

CVSDM; INFORMATION Event Code=400; Description=15
0: Target Sense Key = 0x0b -- Target ASC = 0x47 -- Target ASCQ = 0x00 -- Target
Physical LBA = 0x200 -- DEV_ABORTED_COMMAND_EH The drive returned CHECK CONDITION status indicating an
aborted I/O, which will be retried by the PDD's error recovery algorithms. This event can be seen during the normal operation of the Array, and only represents a problem when it occurs in rapid succession causing a slow down or DEV_IO_FAILED_EH.loop/enclosureId/slot : 0xff/0x00/0x16; controller tick : 39521363119057; serialNum/moduleId/processId : 00PR02149714/0
x3b/0x12d; ; Hardware Address=1/0/12/0/0.2.19.0.0.2.2; FRU Location=M/D7; Vendor
ID=HP; Model ID=A6218A; Product S/N=00USE00003AC; Latest information on this event at http://docs.hp.com/hpux/content/hardware/ems/RemoteMonitor.htm#400

I did notice in armdsp -t before and after
the fix this difference:

Before, M/D7 not listed as other M/D dirves
but listed at the bottom of output:

Disk Controller paths to Encl Hard Assigned
Fru disks Addr Addr Addr
------- ------------------- ---- ---- --------
M/D6 (M/C2.J1, M/C1.J1)* 0x74 0x74 0x74
M/D8 (M/C2.J1, M/C1.J1)* 0x76 0x76 0x76

Not listed after M/D6 above but at bottom
as:

M/D7 (-------, M/C1.J2)* 0x75 0x75 0x75

Now after disk reset of M/D7 disk they are listed
in order:

M/D6 (M/C2.J1, M/C1.J1)* 0x74 0x74 0x74
M/D7 (M/C2.J1, M/C1.J1)* 0x75 0x75 0x75
M/D8 (M/C2.J1, M/C1.J1)* 0x76 0x76 0x76

It is also listed as a possible map disk
in armdsp -a and may be why it was causing
the warning if a map update failed on it
after replacing the two other failed drives.