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: 2398 bytes --]

On Sat, 24 Dec 2011 19:24:37 -0500, Phil Turmel <philip@turmel.org> wrote:
> On 12/24/2011 10:54 AM, Roger Heflin wrote:
> > On my Seagates I turned down the SCTERC to really low (ie .2 seconds)
> > and from what I could see it did not make an obvious difference in
> > the length of the time that the system paused, the pauses appeared to
> > stay at about 30 seconds...which I guess implies that the actual read
> > failed timeout was being hit rather than the disk returning an error
> > in a reasonable time...from the log each time it was forcing a
> > re-write it appeared to be 8 sections of 8 sector each so 32k of
> > data, 64 sectors.    I seem to remember there is a way to turn down
> > the disk op timeout...but at least on my system turning it down lower
> > would mean that the disks might not have enough time to spinup out of
> > a sleep...
> 
> On the drives I've checked closely, any SCTERC setting below 6.5 seconds
> is discarded and treated as zero (no limit).  Setting timeouts in the
> driver stack below the timeout in the drive is counterproductive, as
> drives won't abandon the error recovery attempt to reply to the controller's
> next command.  So the drive gets kicked out of the array as completely
> failed (unresponsive) instead of dealing with the localized read
> error.

Well, that's fair enough, but I'm guessing that it would be relatively
cheap to notice the fact that the read took _ages_ to return, and treat
that as a failure of sorts, even if the drive eventually claims success.

Then, at least the sector would be rewritten, which would either solve
the problem by refreshing the data, or provoke the sector to be re-mapped
if the physical sector was really damaged.  That way you'd not be
constantly bumping into the same pending sectors, provoking extended
read attempts, and thus degrading the whole system's performance.

Alternatively, some way of nudging mdadm into rewriting a sector in one
device from wherever it's stored elsewhere in a RAID, could be combined
with something looking for read failures in the logs, without needing to
add any extra checks to the normal operational code.

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 --]