From: Phil Turmel <philip@turmel.org>
To: Peter Zieba <pzieba@networkmayhem.com>
Cc: linux-raid@vger.kernel.org
Subject: Re: Raid 6 - TLER/CCTL/ERC
Date: Wed, 06 Oct 2010 07:57:58 -0400 [thread overview]
Message-ID: <4CAC6446.3080204@turmel.org> (raw)
In-Reply-To: <556404795.674.1286344296358.JavaMail.root@mail.networkmayhem.com>
On 10/06/2010 01:51 AM, Peter Zieba wrote:
> Hey all,
>
> I have a question regarding Linux raid and degraded arrays.
>
> My configuration involves:
> - 8x Samsung HD103UJ 1TB drives (terrible consumer-grade)
> - AOC-USAS-L8i Controller
> - CentOS 5.5 2.6.18-194.11.1.el5xen (64-bit)
> - Each drive has one maximum-sized partition.
> - 8-drives are configured in a raid 6.
>
> My understanding is that with a raid 6, if a disk cannot return a given sector, it should still be possible to get what should have been returned from the first disk, from two other disks. My understanding is also that if this is successful, this should be written back to the disk that originally failed to read the given sector. I'm assuming that's what a message such as this indicates:
> Sep 17 04:01:12 doorstop kernel: raid5:md0: read error corrected (8 sectors at 1647989048 on sde1)
>
> I was hoping to confirm my suspicion on the meaning of that message.
>
> On occasion, I'll also see this:
> Oct 1 01:50:53 doorstop kernel: raid5:md0: read error not correctable (sector 1647369400 on sdh1).
>
> This seems to involved the drive being kicked from the array, even though the drive is still readable for the most part (save for a few sectors).
[snip /]
Hi Peter,
For read errors that aren't permanent (gone after writing to the affected sectors), a "repair" action is your friend. I used to deal with occasional kicked-out drives in my arrays until I started running the following script in a weekly cron job:
#!/bin/bash
#
for x in /sys/block/md*/md/sync_action ; do
echo repair >$x
done
HTH,
Phil
next prev parent reply other threads:[~2010-10-06 11:57 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <904330941.660.1286340548064.JavaMail.root@mail.networkmayhem.com>
2010-10-06 5:51 ` Raid 6 - TLER/CCTL/ERC Peter Zieba
2010-10-06 11:57 ` Phil Turmel [this message]
2010-10-06 20:14 ` Richard Scobie
2010-10-06 20:24 ` John Robinson
2010-10-07 0:45 ` Michael Sallaway
[not found] <30914146.21286374217265.JavaMail.SYSTEM@ninja>
2010-10-06 14:12 ` Lemur Kryptering
2010-10-06 21:22 ` Stefan /*St0fF*/ Hübner
[not found] <6391773.361286404984328.JavaMail.SYSTEM@ninja>
2010-10-06 22:51 ` Lemur Kryptering
[not found] <8469417.401286406060921.JavaMail.SYSTEM@ninja>
2010-10-06 23:11 ` Lemur Kryptering
2010-10-08 5:47 ` Stefan /*St0fF*/ Hübner
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=4CAC6446.3080204@turmel.org \
--to=philip@turmel.org \
--cc=linux-raid@vger.kernel.org \
--cc=pzieba@networkmayhem.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.