Re: RAID1 seems not to be able to scrub pending sectors shown by smart

[Philip Hands <phil@hands.com>]

[-- Attachment #1: Type: text/plain, Size: 1860 bytes --]

On Fri, 23 Dec 2011 13:59:21 -0600, Roger Heflin <rogerheflin@gmail.com> wrote:
> On Fri, Dec 23, 2011 at 12:39 PM, Philip Hands <phil@hands.com> wrote:
...
> I had 4 1.5tb seagate drives from 2009 (bought at different times in
> 2009) and 3 of those 4 started getting lots of bad sector all within a
> 2 month period and all 3 finally officially failed smart.and when the
> sectors (one after another...lucky they failed out aover 2-3 weeks so
> I had got the replacements in before I lost data-I was down to no
> redundancy for several days in the middle) were failing and being
> rewritten the performance was just ugly--so even if raid1 was
> rewriting the drives it does not do anything for performance when the
> drives are going bad...the only thing that solved my performance was
> getting all of the failing devices to finally fail smart so they could
> be RMAed and replaced at minimal cost..

Well, I suppose that's to some extent the reason I mentioned this.

It seems to me that if a disk is throwing _loads_ of read errors, and
running dreadfully slowly, one could react to that by favouring
different disk(s), and only occasionally throwing a read at the duff
disk, until it either sorts itself out or dies.

My performance went from rubbish to fine simply by removing the
360-pending-sector disk from the RAID.  OK, so if the problem is that
writes are being delayed by the dodgy disk, that's not easy to deal
with, but looking at the logs makes it look like the reads quite often
keep targeting the same disk even when several reads just failed and
got redirected.  This seems suboptimal to me.

Cheers, Phil.
-- 
|)|  Philip Hands [+44 (0)20 8530 9560]    http://www.hands.com/
|-|  HANDS.COM Ltd.                    http://www.uk.debian.org/
|(|  10 Onslow Gardens, South Woodford, London  E18 1NE  ENGLAND

[-- Attachment #2: Type: application/pgp-signature, Size: 835 bytes --]