From mboxrd@z Thu Jan 1 00:00:00 1970
Return-Path: <gentoo-user+bounces-148521-garchives=archives.gentoo.org@lists.gentoo.org>
Received: from lists.gentoo.org (unknown [208.92.234.80])
by finch.gentoo.org (Postfix) with ESMTP id 8BC3A1381F3
for <garchives@archives.gentoo.org>; Tue, 9 Jul 2013 23:58:19 +0000 (UTC)
Received: from pigeon.gentoo.org (localhost [127.0.0.1])
by pigeon.gentoo.org (Postfix) with SMTP id 6633FE0D9B;
Tue, 9 Jul 2013 23:55:54 +0000 (UTC)
Received: from mail-pa0-f43.google.com (mail-pa0-f43.google.com [209.85.220.43])
(using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits))
(No client certificate requested)
by pigeon.gentoo.org (Postfix) with ESMTPS id 4AD0CE0D6E
for <gentoo-user@lists.gentoo.org>; Tue, 9 Jul 2013 23:55:53 +0000 (UTC)
Received: by mail-pa0-f43.google.com with SMTP id hz11so6070151pad.16
for <gentoo-user@lists.gentoo.org>; Tue, 09 Jul 2013 16:55:52 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=gmail.com; s=20120113;
h=mime-version:sender:in-reply-to:references:from:date
:x-google-sender-auth:message-id:subject:to:content-type;
bh=M5cjDMUlg2OYM511YQp3ThgEFMBz7c4Mfgp7eOQ24P4=;
b=wXtkL/eFhohnEYDDEAShKQg+X/zsoKZLTxHplhzzJW1PUtDWgzb2z0QyWMQDlG6wNw
4iEBUp34LZt92wMrUZXAL0E7qgXE3dG6tjp0rpslSdIfXJYK/jU9u4S3KfQuNT+xX3wp
zVos/0obMLRESfXneXc/QWQBjUSFkl2P4ok1WrN+Ys5/Y1C8351blRZjJ8CqLjBReL5N
FkGNyc/Jqqzm5GJMZU8yhmhnQ8bK2hs+GdNaR0Mk5P+0GEAasx72kobirLhMMoN6o+xO
JJtoum64NWtsKk13mpiqDrfrwoNBNIoWwvE2lrz/tn8AJHte73BpfoMY2osbHicnFXxL
MhmQ==
X-Received: by 10.68.221.138 with SMTP id qe10mr23477727pbc.103.1373323756879;
Mon, 08 Jul 2013 15:49:16 -0700 (PDT)
Precedence: bulk
List-Post: <mailto:gentoo-user@lists.gentoo.org>
List-Help: <mailto:gentoo-user+help@lists.gentoo.org>
List-Unsubscribe: <mailto:gentoo-user+unsubscribe@lists.gentoo.org>
List-Subscribe: <mailto:gentoo-user+subscribe@lists.gentoo.org>
List-Id: Gentoo Linux mail <gentoo-user.gentoo.org>
X-BeenThere: gentoo-user@lists.gentoo.org
Reply-to: gentoo-user@lists.gentoo.org
MIME-Version: 1.0
Sender: paul.hartman@gmail.com
Received: by 10.70.62.105 with HTTP; Mon, 8 Jul 2013 15:48:56 -0700 (PDT)
In-Reply-To: <51DB04AE.4050803@xunil.at>
References: <51D33059.5070508@xunil.at> <CAEH5T2PU4CQNN4EGE+AB+C_-H6ae=UVgoYADx5ZCy75QtoofVw@mail.gmail.com>
<51D3D2D2.9020301@xunil.at> <CAEH5T2Ps9Wp-LoaZhTRkTG6v04dKiqxsGjYF=GMmKEP-yn=u_g@mail.gmail.com>
<51D53EA6.6050004@xunil.at> <CAEH5T2Md1vT2L46wuUqi+EQGUC3tW84yojgmK_J6Z3ZNx6GMVQ@mail.gmail.com>
<CAEH5T2Mvo5xzowMPd=iK=4yf=Mm627y4KBLJ+2Cp5R0zd-fWFA@mail.gmail.com>
<51DAE18C.2010804@gmail.com> <51DB04AE.4050803@xunil.at>
From: Paul Hartman <paul.hartman+gentoo@gmail.com>
Date: Mon, 8 Jul 2013 17:48:56 -0500
X-Google-Sender-Auth: 891nCgwdbBah-6CTK7KBEshVlIU
Message-ID: <CAEH5T2MgPVsGHW5VQB-1FDMdZC9pQ7sfK6ERBiiDrRa9JjDLeg@mail.gmail.com>
Subject: Re: [gentoo-user] hp H222 SAS controller
To: gentoo-user@lists.gentoo.org
Content-Type: text/plain; charset=ISO-8859-1
X-Archives-Salt: 74dede67-dcf0-41f4-aca3-aaa1c076743b
X-Archives-Hash: 2cc13ceac2d65ea4265292d3dec3a74a
On Mon, Jul 8, 2013 at 1:27 PM, Stefan G. Weichinger <lists@xunil.at> wrote:
> Does it make sense to apply some sort of burn-in-procedure before
> actually formatting and using the disks? Running badblocks or something?
>
> I ask because I wait for that shiny new server and doing so might not
> hurt before installing gentoo. Or is that too paranoid and a waste of time?
Initially I ran the SMART long test and it found no errors. Then I did
badblocks read-only scan and it found some bad sectors. After that,
SMART tests failed to complete due to "failure reading LBA xxxxxxxxx".
I used hdparm to remap those sectors, but didn't feel entirely
confident in the disk at that point in time.
So I ran the badblocks destructive read-write test and it completed
(after a couple days) with zero errors! How can it be?
Checking the SMART statistics afterward, I can see now there are
dozens of newly reallocated sectors. So that means the drive silently
replaced those bad sectors with spares, which is good! That is what it
is supposed to do! I don't feel happy about the fact that those bad
sectors exist in the first place, but the drive did what it was
designed to do when it encountered them.
After the r/w badblocks test cycle finished, I ran SMART long-scan
again and this time it completed with no errors.
So I recommend to do the destructive read-write badblocks test, if you
can afford the hours (or days) spent waiting for it to complete.
SMART alone did not detect the errors initially, but neither did
badblocks actually identify the errors during its write test (because
the drive hides it). But the combination of badblocks and the
self-repairing code in the drive's firmware accomplished the goal of
making my disk free of errors (logically).
Notes:
WARNING! Be careful to give the correct device name when doing the
badblocks write test! There is no confirmation prompt! It immediately
starts destroying data at the beginning of the disk.
If you have a disk with 4k sector size, be sure to tell badblocks to
use a 4096 byte block size. It uses 1k block size by default, which
can cause the test to be very slow! In my system badblocks with 1k
block size read at 15MB/sec, while 4k block size read at over
160MB/sec! Using 1k block size on a 4k-sector disk also causes all
errors to be reported 4 times each.
Good luck :)