Peter -

On Mon, 31 Jan 2005 09:57:23 +0100, Peter C. Tribble wrote
(in article <ctkrtj$56v$1@helium.hgmp.mrc.ac.uk>):

[...]

> Looks more like a SCSI glitch rather than a disk error as such (although then

> the question is - what caused the glitch? In the absence of any other errors
> it's not obvious. Does iostat -E give any clues?)

I have a script running a stripped iostat -nE every morning at six and I did
have a few alerts but none but the last were bad enough to switch to the hot
spare.

That's the full history (s/w h/w trn tot ):

0 0 0 0 c0t2d0 (brand new disk installed on May 26)
0 1 0 1 c0t2d0 (first error on Sept 25)
5 1 0 6 c0t2d0 (Oct 27)
5 3 0 8 c0t2d0 (Jan 15)
5 6 0 11 c0t2d0 (Jan 20)
5 9 0 14 c0t2d0 (Jan 29)
5 23 6 34 c0t2d0 (switch to hot spare on Jan 30)
0 0 0 0 c0t2d0 (back to normal on Jan 31 after metareplace)

Note that I do have from time to time, on all disks, both internal and
external) software errors (5 above). I tought of a bug in LVM.

[...]

> As I said, I would always do a format/analyze/read test.
>
> (The resync only does writes...so isn't a full test.)

OK, you meant a non destructive test. I'll do that.

Thanks !

Georges

--
Georges Tomazi - gt@diapason.com