Is this disk healthy or about to die ??

Hi there, at just past midday yesterday, we had this message from one of
our machines, just one ! ... and it hadn't happened before ..... iostat
-E doesn't suggest the disk is experiencing ongoing issues (see iostat
snippet below the messages).

I can access the slice mounted on the disk with no issues....


# cat /var/adm/messages
May 20 12:07:16 scsi: [ID 107833 kern.warning] WARNING:
/pci@0,0/pci1022,7450@2/pci1000,3060@3/sd@0,0 (sd2):
May 20 12:07:16 SCSI transport failed: reason 'reset': retrying
command
May 20 12:08:10 scsi: [ID 107833 kern.notice]
/pci@0,0/pci1022,7450@2/pci1000,3060@3 (mpt0):
May 20 12:08:10 Physical disk 2 (target 2) is |failed|
May 20 12:08:10 scsi: [ID 107833 kern.notice]
/pci@0,0/pci1022,7450@2/pci1000,3060@3 (mpt0):
May 20 12:08:10 Physical disk 2 (target 2) is |out of sync||failed|
May 20 12:08:10 scsi: [ID 107833 kern.notice]
/pci@0,0/pci1022,7450@2/pci1000,3060@3 (mpt0):
May 20 12:08:10 Volume 0 is |enabled||degraded|



# iostat -E
sd2 Soft Errors: 2 Hard Errors: 0 Transport Errors: 1
Vendor: LSILOGIC Product: Logical Volume Revision: 3000 Serial No:
Size: 73.00GB <72999763456 bytes>
Media Error: 0 Device Not Ready: 0 No Device: 0 Recoverable: 0
Illegal Request: 2 Predictive Failure Analysis: 0



Is this a definitive sign that I need to replace this disk? Or do I need
to wait for more occurrences? Even though iostat says no hard errors
and generally looks healthy, the language in the messages file (eg
failed, degraded, out of sync etc) suggests that I should be immediately
concerned and take action...however as stated above I can access the
disk fine, and iostat seems fine

Any help on this would be greatly appreciated

Cheers
Gary


*****************************************************************************
*****************************************************************************
**********************************
This message is intended only for the stated addressee(s) and may be
confidential. Access to this email by anyone else is unauthorised. Any
opinions expressed in this email do not necessarily reflect the opinions of
Fidessa. Any unauthorised disclosure, use or dissemination, either whole or in
part is prohibited. If you are not the intended recipient of this message,
please notify the sender immediately.

Fidessa plc - Registered office:
Dukes Court, Duke Street, Woking, Surrey, GU21 5BH, United Kingdom
Registered in England no. 3781700 VAT registration no. 688 9008 78

Fidessa group plc - Registered Office:
Dukes Court, Duke Street, Woking, Surrey, GU21 5BH, United Kingdom
Registered in England no. 3234176 VAT registration no. 688 9008 78
_______________________________________________
sunmanagers mailing list
sunmanagers@xxxxxxxxxxxxxxx
http://www.sunmanagers.org/mailman/listinfo/sunmanagers

Relevant Pages

  • Strange Disk behavior - iostat question
    ... I have a disk that's having performance issues so I ran iostat and as you can ... Fidessa plc - Registered office: ... Dukes Court, Duke Street, Woking, Surrey, GU21 5BH, United Kingdom ...
    (SunManagers)
  • Re: Iostat Question (OSF1)
    ... >The output from this example displays cpu, terminal, and disk ... The iostat Command ... The following example shows disk statistics gathered every five ... show statistics for the terminal, disks, and CPU ...
    (comp.unix.solaris)
  • iostat = 100% busy - whats causing this
    ... I have a Solaris 10 x4100 (running sybase) with something making masses ... obvious way of telling what is reading from the disk. ... royalblue financial plc - Registered office: ... Dukes Court, Duke Street, Woking, Surrey, GU21 5BH, United Kingdom ...
    (SunManagers)
  • Re: zfs - move pool to new device?
    ... compare zpool iostat and plain iostat on each disk itself. ... tin tout kps tps serv kps tps serv kps tps serv kps tps serv us sy ...
    (comp.unix.solaris)
  • Re: Determining whether or not a SCSI disk is in use
    ... I'm sorry, I'm an idiot - the script, in its current incarnation, ... do - it will shut down the disk if there was activity. ... Well, iostat updating did seem to be largely cached, so I'm not sure what the best way is of approaching this problem. ... I sure wish the FreeBSD kernel team would work something out where the hard disk would sleep after a period of time in the kernel ACPI wise>_<. ...
    (freebsd-questions)