From: Phil Turmel <philip@turmel.org>
To: thomas@fjellstrom.ca, Mikael Abrahamsson <swmike@swm.pp.se>
Cc: "Wilson, Jonathan" <piercing_male@hotmail.com>,
linux-raid@vger.kernel.org
Subject: Re: Riad scrub generated errors, should I worry?
Date: Mon, 02 Mar 2015 16:09:02 -0500 [thread overview]
Message-ID: <54F4D16E.8070909@turmel.org> (raw)
In-Reply-To: <1786620.4mivBfObx3@balsa>
On 03/02/2015 12:43 PM, Thomas Fjellstrom wrote:
> On Mon 02 Mar 2015 04:22:00 PM Mikael Abrahamsson wrote:
>> On Mon, 2 Mar 2015, Wilson, Jonathan wrote:
>>> While the monthly scrub was running the following errors (at the bottom
>>> of the post, copied from syslog) were issued.
>>
>> As soon as you get UNC, it's the drive reporting that it can't
>> successfully read a sector. Usually this sector is then reported as
>> "pending" in your SMART output.
>>
>> Since the log you provided shows a lot of sectors being corrected and you
>> after that have 0 pending sectors on the drive, I'd say you are now fine.
>> I would run a new scrub manually in a few days just to check, but you
>> might be fine going forward. There is no really good way to know, but
>> generally, a drive that throws a bunch of UNC should be monitored so this
>> isn't becoming a common problem. I tend to replace drives that have thrown
>> these kinds of errors if it happens on any kind of regular basis.
>
> Dumb question, but after pending, I assume they go into the reallocated
> column? I think after a certain number of those, you should start thinking
> about a replacement. Like with my recent issues, I had two drives with a few
> too many reallocated sectors. One was over 16k and the other was over 32k.
> They still "work", but I replaced them with WD Reds anyhow. Another drive
> seemed to max out the start-stop count field at 65536. Hah. No more cheap
> desktop seagates in raid for this fellow.
If the URE was simply due to magnetic decay without actual damage, you
can expect MD to rewrite the sector and fix it. No more pending, no
relocation. If the spot on the media is truly failing, the rewrite and
recheck the drive does for pending sectors will expose the problem, and
the firmware will relocate.
Read errors like this are normal and expected. The drive data shows
10k+ hours of operation, so the honeymoon (no errors at all) is over.
Scrub weekly or monthly so these UREs don't accumulate and carry on.
When actual *relocations* climb into double digits, replace the drive.
HTH,
Phil
next prev parent reply other threads:[~2015-03-02 21:09 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-03-02 14:36 Riad scrub generated errors, should I worry? Wilson, Jonathan
2015-03-02 15:22 ` Mikael Abrahamsson
2015-03-02 17:43 ` Thomas Fjellstrom
2015-03-02 21:09 ` Phil Turmel [this message]
2015-03-02 18:32 ` Chris Murphy
2015-03-02 19:45 ` Wilson, Jonathan
[not found] ` <CAJCQCtTVA6ntASWFtWMw7ZEwu=8jH+UjvN8avPZ8jXZ1_4BQXg@mail.gmail.com>
2015-03-02 21:10 ` Chris Murphy
2015-03-02 21:17 ` Chris Murphy
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=54F4D16E.8070909@turmel.org \
--to=philip@turmel.org \
--cc=linux-raid@vger.kernel.org \
--cc=piercing_male@hotmail.com \
--cc=swmike@swm.pp.se \
--cc=thomas@fjellstrom.ca \
/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.