Boston Linux & UNIX was originally founded in 1994 as part of The Boston Computer Society. We meet on the third Wednesday of each month, online, via Jitsi Meet.

BLU Discuss list archive


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Discuss] hard drive burn-in



Back in 2008-09-19, in the thread:
http://thread.gmane.org/gmane.org.user-groups.linux.boston.discuss/30555/focus=30556

Jarod Wilson wrote:
> I'm partial to running mkfs with full read/write badblocks checking.
> Basically, make a single partition covering the whole disk, then:
> 
> # mkfs.ext3 -c -c /dev/sdx1

'mkfs.ext3 -c' calls out to the 'badblocks' command, passing it
arguments so 'badblocks' does the right thing in the context of an ext3
file system.

I've since had occasion to use the 'badblocks' command directly to fix
up a pending failed sector lingering in a swap partition. Pretty handy
command.

I've also found it can be handy to use it directly for drive burn-in.
For example, this:

badblocks -w -b 4096 -s /dev/sdc

will cause badblocks to destructively (it has non-destructive modes as
well) write 4 different bit patterns to the drive and verify them. You
can do this to the raw device, so that the MBR and partition table areas
also get exercised. (The switch to specify a 4096 block size may be
irrelevant in this context. I simply carried it over from the argument
mkfs.ext3 uses when it calls badblocks, not because block alignment is
needed, but in the hope it might speed up processing over the default
1024 block size.)

It isn't particularly fast. Looks like it is taking 48 hours to write
the 4 patterns to a 500 GB USB connected drive. Maybe the slow USB link
is to blame. I did notice it writes one pattern to the entire drive,
then seeks to the beginning and does the next pattern, rather than
cycling through all 4 patterns before seeking to the next spot.

As recommended in the prior thread, also good to incorporate SMART
monitoring with any burn-in operations. I captured the SMART data from
the drive:

smartctl -d sat -a /dev/sdc

('-d sat' because it is a USB drive; newer smartctl probably doesn't
need it)

and ran a long test:

smartctl -d sat -t long /dev/sdc

prior to starting the burn-in. I'll repeat that after to see if any of
the failure counters have incremented.

 -Tom

-- 
Tom Metro
Venture Logic, Newton, MA, USA
"Enterprise solutions through open source."
Professional Profile: http://tmetro.venturelogic.com/



BLU is a member of BostonUserGroups
BLU is a member of BostonUserGroups
We also thank MIT for the use of their facilities.

Valid HTML 4.01! Valid CSS!



Boston Linux & Unix / webmaster@blu.org