All of lore.kernel.org
 help / color / mirror / Atom feed
From: Phil Turmel <philip@turmel.org>
To: EJ Vincent <ej@ejane.org>
Subject: Re: raid/device failure
Date: Sun, 10 Feb 2013 22:44:00 -0500	[thread overview]
Message-ID: <51186900.4000608@turmel.org> (raw)
In-Reply-To: <51185CDF.8000007@ejane.org>

On 02/10/2013 09:52 PM, EJ Vincent wrote:
> On 2/10/2013 9:09 PM, Phil Turmel wrote:
>> Have these drives ever been scrubbed? (I vaguely recall you mentioning
>> new drives...) If they are new and already had a URE, I'd be concerned
>> about mishandling during shipping. If they aren't new, I'd
>> destructively exercise them and retest.
> 
> Hi Phil,
> 
> Could you elaborate on procedures and tools to thoroughly exercise newly
> purchased drives? Are you talking about programs such as 'badblocks'?

Yes, badblocks is convenient because it is part of e2fsprogs, which
pretty much ships by default in all distros.

What I recommend:

Record the complete drive status as unpacked:
1) smartctl -x /dev/sdX >xxxx-as-received.smart.txt

Userspace surface check:
2) badblocks -w -b 4096 /dev/sdX

Security erase (vital for SSDs):
3a) hdparm --user-master u --security-set-pass password /dev/sdX
3b) hdparm --user-master u --security-erase password /dev/sdX

(wait until done)

Long drive self-test:
4) smartctl -t long /dev/sdX

(wait until done)

Record the complete drive status post-test:
5) smartctl -x /dev/sdX >xxxx-as-tested.smart.txt

I won't accept any reallocations in a new drive, and no more than single
digits in older drives.  In my (subjective) experience, once
reallocations get into double digits, their incidence seems to accelerate.

I also pay extra attention to desktop drives with 30,000+ hours, as I
haven't had any get to 40,000.

Phil

  reply	other threads:[~2013-02-11  3:44 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-02-11  1:27 raid/device failure Thomas Fjellstrom
2013-02-11  2:09 ` Phil Turmel
2013-02-11  2:52   ` EJ Vincent
2013-02-11  3:44     ` Phil Turmel [this message]
2013-02-11 20:28       ` EJ Vincent
2013-02-11  2:55   ` Thomas Fjellstrom
2013-02-11  3:22 ` Brad Campbell
2013-02-11  7:55   ` Thomas Fjellstrom
2013-02-11  8:29 ` Roy Sigurd Karlsbakk
2013-02-11  9:13   ` Thomas Fjellstrom
2013-02-12 22:31 ` Thomas Fjellstrom

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=51186900.4000608@turmel.org \
    --to=philip@turmel.org \
    --cc=ej@ejane.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.