| T.R | Title | User | Personal
Name | Date | Lines |
|---|
| 901.1 | Locate command???? | SSDEVO::RMCLEAN | | Wed Jun 04 1997 12:51 | 1 |
| Did you do a locate command with the CLI?
|
| 901.2 | did not need locate. | TROFS::S_OSSOWSKI | STEPHEN OSSOWSKI @TRO | Wed Jun 04 1997 12:55 | 5 |
| The fault light was on . Did not need to do a locate. The problem is
that the disk was not moved to the failedset and was being accessed
with the yellow led on.
|
| 901.3 | locate clarification | TROFS::S_OSSOWSKI | STEPHEN OSSOWSKI @TRO | Wed Jun 04 1997 13:12 | 5 |
| Ok. I know I can do a LOCATE CANCEL to turn off the led. In this
situation it was clear from UERF that there was a loggable event and
something was happening to the mirrored pair.
|
| 901.4 | | SSDEVO::T_GONZALES | | Wed Jun 04 1997 18:06 | 5 |
| was the orange led blinking or lit continuously? What type of shelf
were you using ba350 or ba356 with i/o module? If the light were on
solid,then the fault led could have become falsely latched.
|
| 901.5 | ba350 | TROFS::S_OSSOWSKI | STEPHEN OSSOWSKI @TRO | Thu Jun 05 1997 08:15 | 15 |
| It was in a BA350 within a SW500. (ie no personality module)
How would you define a blinking fault led? Since I was not on site
myself I am relying on second hand info about led status. I am told ON
solid. My concern is again: what type of fault condition (beside locate
CLI) would NOT put the disk in the failedset. You say "falsely latched"
, of what consequence is this for the mirrorset. I beleive the host
should not be impacted at all (besides logging an event).
This is important because the first sign of a problem from the host's
perspective was that one Unix Application would not run(don't have details
yet) hence the discovery of one faulted drive in a two drive mirror.
The system had to be rebooted to allow app execution (cache flush - unix or
hsz???). Then the disk was swapped by MCS.
|
| 901.6 | | SSDEVO::T_GONZALES | | Thu Jun 05 1997 10:29 | 5 |
| A blinking fault light, is either set by the locate command or is
set because the hsz has put the device into the failed set. If the
fault light is on steady and not blinking, the device may
not have ever become ready to the hsz. Did this condition occur after
a power up or a reboot of the hsz?
|
| 901.7 | customer confidence | TROFS::S_OSSOWSKI | STEPHEN OSSOWSKI @TRO | Thu Jun 05 1997 11:07 | 14 |
| The fault was discovered by the customer because they were having some
sort of application failure and decided to go look at the arrays.
The exact timing of this fault is in question. I believe that if it
occured any time near(no more than the few prior sec'/min's) it just
might be related, if not then it is a prior failure with nothing to do
with the app. That reasoning is based on the fact that it was
NOT in the failedset and no one looked at the mirror status info.
The customer at the momemt beleives that this 0+1 setup did not provide
them with DATA RELIABILITY. I am trying calm the storm.
Does this make sense?
|