All of lore.kernel.org
 help / color / mirror / Atom feed
From: David Greaves <david@dgreaves.com>
To: Kevin Shanahan <kmshanah@disenchant.net>
Cc: David Lethe <david@santools.com>, linux-raid@vger.kernel.org
Subject: Re: Read errors and SMART tests
Date: Sat, 20 Dec 2008 21:46:20 +0000	[thread overview]
Message-ID: <494D67AC.3060008@dgreaves.com> (raw)
In-Reply-To: <20081220090909.GO1749@cubit>

Kevin Shanahan wrote:
> Of the remaining drives, SMART attributes for /dev/sd[cghijkl] all show:
> 
>   196 Reallocated_Event_Count 0x0032   100   100   000    Old_age   Always       -       0
>   197 Current_Pending_Sector  0x0012   100   100   000    Old_age   Always       -       0
> 
> /dev/sde shows:
> 
>   196 Reallocated_Event_Count 0x0032   100   100   000    Old_age   Always       -       0
>   197 Current_Pending_Sector  0x0012   100   100   000    Old_age   Always       -       3
> 
> /dev/sdf shows:
> 
>   196 Reallocated_Event_Count 0x0032   100   100   000    Old_age   Always       -       2
>   197 Current_Pending_Sector  0x0012   100   100   000    Old_age   Always       -       0
> 
> Unfortunately the original /dev/sdd isn't currently attached, but I'll
> hook that up on Monday and check. I'd expect to see some high numbers
> there.
> 
>> These errors could be
>> Result of something relatively benign, like unexpected power loss.
> 
> Sorry, are you saying that about the errors from libata layer or just
> the errors from the md layer?

I wouldn't dream of contradicting David and I'm sure you've got nothing to worry
about. What's a few bad blocks between friends anyway :)

I will say that I have had very similar problems.

I used ddrescue to read the area around the block until it read without error,
and then re-wrote it. A subsequent smartctl -tlong /dev/sdX would then show no
errors.

In my experience the bad blocks returned regularly and I became very familiar
indeed with forced rebuilds of arrays, array re-creation and other mdadm
incantations as the errors hit the system.

I will say that I've returned a *lot* of these under RMA (after discussions with
Samsung engineers).

Any drive that returns *fail* for a built-in self-test now gets 1 chance and is
then RMAed.

David

-- 
"Don't worry, you'll be fine; I saw it work in a cartoon once..."

  reply	other threads:[~2008-12-20 21:46 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-12-20  1:30 Read errors and SMART tests Kevin Shanahan
2008-12-20  4:13 ` David Lethe
2008-12-20  5:22   ` Kevin Shanahan
2008-12-20  6:54     ` David Lethe
2008-12-20  9:09       ` Kevin Shanahan
2008-12-20 21:46         ` David Greaves [this message]
2009-01-14 20:59     ` Bill Davidsen

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=494D67AC.3060008@dgreaves.com \
    --to=david@dgreaves.com \
    --cc=david@santools.com \
    --cc=kmshanah@disenchant.net \
    --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 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.