Gentoo Archives: gentoo-user

From: "Stefan G. Weichinger" <lists@×××××.at>
To: gentoo-user@l.g.o
Subject: Re: [gentoo-user] hp H222 SAS controller
Date: Wed, 10 Jul 2013 17:14:22
Message-Id: 51DD9660.9080906@xunil.at
In Reply to: Re: [gentoo-user] hp H222 SAS controller by Paul Hartman
1 Am 09.07.2013 00:48, schrieb Paul Hartman:
2 > On Mon, Jul 8, 2013 at 1:27 PM, Stefan G. Weichinger <lists@×××××.at> wrote:
3 >> Does it make sense to apply some sort of burn-in-procedure before
4 >> actually formatting and using the disks? Running badblocks or something?
5 >>
6 >> I ask because I wait for that shiny new server and doing so might not
7 >> hurt before installing gentoo. Or is that too paranoid and a waste of time?
8 >
9 > Initially I ran the SMART long test and it found no errors. Then I did
10 > badblocks read-only scan and it found some bad sectors. After that,
11 > SMART tests failed to complete due to "failure reading LBA xxxxxxxxx".
12 > I used hdparm to remap those sectors, but didn't feel entirely
13 > confident in the disk at that point in time.
14 >
15 > So I ran the badblocks destructive read-write test and it completed
16 > (after a couple days) with zero errors! How can it be?
17 >
18 > Checking the SMART statistics afterward, I can see now there are
19 > dozens of newly reallocated sectors. So that means the drive silently
20 > replaced those bad sectors with spares, which is good! That is what it
21 > is supposed to do! I don't feel happy about the fact that those bad
22 > sectors exist in the first place, but the drive did what it was
23 > designed to do when it encountered them.
24 >
25 > After the r/w badblocks test cycle finished, I ran SMART long-scan
26 > again and this time it completed with no errors.
27 >
28 > So I recommend to do the destructive read-write badblocks test, if you
29 > can afford the hours (or days) spent waiting for it to complete.
30 >
31 > SMART alone did not detect the errors initially, but neither did
32 > badblocks actually identify the errors during its write test (because
33 > the drive hides it). But the combination of badblocks and the
34 > self-repairing code in the drive's firmware accomplished the goal of
35 > making my disk free of errors (logically).
36 >
37 > Notes:
38 >
39 > WARNING! Be careful to give the correct device name when doing the
40 > badblocks write test! There is no confirmation prompt! It immediately
41 > starts destroying data at the beginning of the disk.
42 >
43 > If you have a disk with 4k sector size, be sure to tell badblocks to
44 > use a 4096 byte block size. It uses 1k block size by default, which
45 > can cause the test to be very slow! In my system badblocks with 1k
46 > block size read at 15MB/sec, while 4k block size read at over
47 > 160MB/sec! Using 1k block size on a 4k-sector disk also causes all
48 > errors to be reported 4 times each.
49 >
50 > Good luck :)
51
52 Thanks for your explanations, Paul ... I will see if I have the patience
53 to wait for hours or days :-)
54
55 Stefan