Date: Tue, 21 Aug 2007 20:42:05 +0930 From: "Daniel O'Connor" <doconnor@gsoft.com.au> To: "Artem Kuchin" <matrix@itlegion.ru> Cc: freebsd-stable@freebsd.org, Martin Nilsson <martin@gneto.com> Subject: Re: A little story of failed raid5 (3ware 8000 series) Message-ID: <200708212042.13616.doconnor@gsoft.com.au> In-Reply-To: <00c901c7e3d9$e6134760$0c00a8c0@Artem> References: <028f01c7e37a$d8f441b0$0c00a8c0@Artem> <200708211606.00429.doconnor@gsoft.com.au> <00c901c7e3d9$e6134760$0c00a8c0@Artem>
next in thread | previous in thread | raw e-mail | index | archive | help
[-- Attachment #1 --] On Tue, 21 Aug 2007, Artem Kuchin wrote: > Now, what i don't understand is why Hardware_ECC_Recovered and > Seek_Error_Rate are so hight. The first one is maybe relate > to cabling problem. The driver are all in hot swap baskets of > supermicro 2u case. Maybe backpanel is no so good? > > Seek_Error_Rate is a mistety for me. Any idea? I don't know what the problem is, I would have expected the drive to report errors in it's log if it is genuinely failing (I've seen this on my laptop) Have you tried running SMART tests on the disk? I'm not saying SMART is the be all and end all of failure monitoring but it has indicated problems to me in the past :) -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C [-- Attachment #2 --] -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4 (FreeBSD) iD8DBQBGysiN5ZPcIHs/zowRAoeyAJwOzhe5HiVwAY4Bi0xhYooj160g2gCgm6tc EtimjogslakzOF4xIRBxCHc= =A8yi -----END PGP SIGNATURE-----
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200708212042.13616.doconnor>