BLU Discuss list archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Discuss] hard drive burn-in
- Subject: [Discuss] hard drive burn-in
- From: tmetro+blu at gmail.com (Tom Metro)
- Date: Thu, 04 Oct 2012 22:45:31 -0400
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/
- Prev by Date: [Discuss] Looking for some good people at my company
- Next by Date: [Discuss] [Position-available] Linux Engineer - Boston
- Previous by thread: [Discuss] Looking for some good people at my company
- Next by thread: [Discuss] [Position-available] Linux Engineer - Boston
- Index(es):