linux-raid.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Giovanni Tessore <giotex@texsoft.it>
To: linux-raid@vger.kernel.org
Subject: Re: read errors corrected
Date: Sat, 15 Jan 2011 13:00:06 +0100	[thread overview]
Message-ID: <4D318C46.7060204@texsoft.it> (raw)
In-Reply-To: <AANLkTimm6P=Lb1uzC83Va323V+Q0e1xSzFfuc2ze-8Fp@mail.gmail.com>

On 12/30/2010 05:41 PM, James wrote:
> Inline.
>
> On Thu, Dec 30, 2010 at 05:13, Giovanni Tessore<giotex@texsoft.it>  wrote:
>> On 12/30/2010 04:20 AM, James wrote:
>>> Can someone point me in the right direction?
>>> (a) what causes these errors precisely?
>>> (b) is the error benign? How can I determine if it is *likely* a
>>> hardware problem? (I imagine it's probably impossible to tell if it's
>>> HW until it's too late)
>>> (c) are these errors expected in a RAID array that is heavily used?
>>> (d) what kind of errors should I see regarding "read errors" that
>>> *would* indicate an imminent hardware failure?
>> (a) these errors usually come from defective disk sectors. raid recostructs
>> the missing sector from parity from other disks in the array, then rewrites
>> the sector on the defective disk; if the sector is rewritten without error
>> (maybe the hd remaps the sector into its reserved area), then just the log
>> messages is displayed.
>>
>> (b) with raid-6 it's almost benign; to get troubles you should get a read
>> error on same sector for>2 disks; or have 2 disks failed and out of the
>> array and get a read error on one of the other disks while recostructing the
>> array; or have 1 disk failed and get a read error on same sector on>1 disk
>> while recostructing (with raid-5 it's almost dangerous instead, as you can
>> have big troubles if a disk fails and you get a read error on another disk
>> while recostructing; that happened to me!)
>>
>> (c) no; it's also a good rule to perform a periodic scrub of the array
>> (check of the array), to reveal and correct defective sectors
>>
>> (d) check smart status of the disks, for "relocated sectors count"; also if
>> md superblock is>= 1 there is a persistent count of corrected read errors
>> for each device into /sys/block/mdXX/md/dev-XX/errors, when this counter
>> reaches 256 the disk is marked failed; ihmo when a disk is giving even few
>> corrected read errors in a short interval its better to replace it.
> Good call.
>
> Here's the output of the reallocated sector count:
>
> ~ # for i in a b c d ; do smartctl -a /dev/sd$i | grep Realloc ; done
>    5 Reallocated_Sector_Ct   0x0033   100   100   036    Pre-fail
> Always       -       1
>    5 Reallocated_Sector_Ct   0x0033   100   100   036    Pre-fail
> Always       -       3
>    5 Reallocated_Sector_Ct   0x0033   100   100   036    Pre-fail
> Always       -       5
>    5 Reallocated_Sector_Ct   0x0033   100   100   036    Pre-fail
> Always       -       1
>
> Are these values high? Low? Acceptable?
>
> How about values like "Raw_Read_Error_Rate" and "Seek_Error_Rate" -- I
> believe I've read those are values that are normally very high...is
> this true?
>
> ~ # for i in a b c d ; do smartctl -a /dev/sd$i | grep
> Raw_Read_Error_Rate ; done
>    1 Raw_Read_Error_Rate     0x000f   116   099   006    Pre-fail
> Always       -       106523474
>    1 Raw_Read_Error_Rate     0x000f   114   099   006    Pre-fail
> Always       -       77952706
>    1 Raw_Read_Error_Rate     0x000f   117   099   006    Pre-fail
> Always       -       137525325
>    1 Raw_Read_Error_Rate     0x000f   118   099   006    Pre-fail
> Always       -       179042738
>
> ...and...
>
>   ~ # for i in a b c d ; do smartctl -a /dev/sd$i | grep
> Seek_Error_Rate ; done
>    7 Seek_Error_Rate         0x000f   072   060   030    Pre-fail
> Always       -       14923821
>    7 Seek_Error_Rate         0x000f   072   060   030    Pre-fail
> Always       -       15648709
>    7 Seek_Error_Rate         0x000f   072   060   030    Pre-fail
> Always       -       15733727
>    7 Seek_Error_Rate         0x000f   071   060   030    Pre-fail
> Always       -       14279452
>
> Thoughts appreciated.
>

As I know,  Reallocated_Sector_Ct is the most meaningful SMART parameter 
related to disk sectors health.
Also check for Current_Pending_Sector (sector that gave read on error 
and has not been reallocated yet).
The values of your disks seems quite safe at the moment.
Be proactive if the value grows in short time.

I had same problem this week, one of my disk gave >800 reallocated read 
errors.
The disk was still marked good and alive into array, but I replaced it 
immediately.

Regards.

-- 
Cordiali saluti.
Yours faithfully.

Giovanni Tessore



  reply	other threads:[~2011-01-15 12:00 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-12-30  3:20 read errors corrected James
2010-12-30  5:24 ` Mikael Abrahamsson
2010-12-30 16:33   ` James
2010-12-30 16:44     ` Roman Mamedov
2010-12-30 16:51       ` James
2010-12-30 17:59         ` Ryan Wagoner
2010-12-30 18:03           ` James
2010-12-30  9:15 ` Neil Brown
     [not found]   ` <AANLkTik2+Gk1XveqD=crGMH5JshzJqQb_i77ZpOFUncB@mail.gmail.com>
2010-12-30 16:35     ` James
2010-12-30 23:12       ` Neil Brown
2010-12-31  1:48         ` James
2010-12-31  1:56           ` Guy Watkins
2010-12-31  2:08           ` Neil Brown
2010-12-30 10:13 ` Giovanni Tessore
2010-12-30 16:41   ` James
2011-01-15 12:00     ` Giovanni Tessore [this message]
2011-01-16  8:33       ` Jaap Crezee
  -- strict thread matches above, loose matches on Subject: below --
2010-12-30 20:19 Richard Scobie

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4D318C46.7060204@texsoft.it \
    --to=giotex@texsoft.it \
    --cc=linux-raid@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).