Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

I'll be creating a 6drive RAID 5 array for use with Openfiler. What I'd like to do is test the drives thoroughly before building the array and putting them into production. What free software is best suited for this, and does any software allow you to test multiple drives at once?

I'll be testing 2tb Hitachi 5K3000 5400 rpm drives.

share|improve this question
4  
I would strongly advise against building a raid5 array with 6 2TB drives, especially if you bought them all at the same time. If one of them fails the chance of a 2nd failure during the rebuild is very high. You should at least use raid6. –  JamesRyan Apr 21 '11 at 21:26
    
I'm aware of the RAID 5 failures on rebuild. This is why i'd like to check them now. I'll be backing up the important data off these disks to another set of disks. But not all the data... I'm considering ZFS instead of RAID 5 but am not 100%.. The serveraid 8k card doesn't support RAID 6 either.. so that complicates matters way past just throwing another 80.00 at the server for an additional disk. –  Garuda Apr 22 '11 at 2:54
    
Well there is always raid 10 –  JamesRyan Apr 22 '11 at 12:03
    
@JamesRyan exactly right, Garuda, read this paper: queue.acm.org/detail.cfm?id=1670144 before going for a 10TB array... –  Hubert Kario Apr 22 '11 at 17:48
add comment

3 Answers

You didn't say which operating system you're on...

On Windows, my workflow for burn-in testing harddisks now tends to be:

  1. Attach the drive as a non-system drive (i.e. attach it as a secondary drive to an existing Windows installation).
  2. Run Crystal Disk Info or another S.M.A.R.T tool on the drive, record most important stats on paper.
  3. Format the drive 2-3 times via Truecrypt as a full-disk encrypted volume. This will ensure that the drive gets completely overwritten with random (encrypted) data. Doing this from within Windows sidesteps all issues about some DOS boot disk not seeing large drives, some BIOS'es having problems with large drives, etc.
  4. Run the S.M.A.R.T tool again, and compare values, especially the number of re-mapped (bad) blocks. If this is significant, don't use the drive.

For Linux, @Hubert Kario's badblocks suggestion seems a good one.

You can also use the manufacturer's "drive fitness test" or similar. Most manufacturers have this kind of tool, and it generally contains a long & data-destructive drive test which zero-fills the drive.

On the good side, the manufacturers own tool might provide an error code, which is accepted as grounds for warranty replacement. On the bad side, I just find Truecrypt faster and easier to deal with, and at least as thorough.

The Ultimate Boot CD has a collection of reasonably up to date versions of these manufacturer-specific tools, see the section "Hard Disk Diagnosis".

Nota bene: This kind of burn-in test should never be performed on SSD's. It does no good for SSD's, but causes a fair amount of wear to them.

share|improve this answer
    
ugh. I think i screwed up. I used the onboard SAS Raid controller to do a verify. It remaps bad blocks.. but it didn't tell me if it did any. It just said drive verify complete. There's no log file. So I have no clue if there are any bad blocks!! Thoughts? –  Garuda Apr 24 '11 at 15:53
    
@Garuda: I cannot be 110% sure here, but I would strongly assume that a S.M.A.R.T monitoring tool like the one I mention above should still report the remapped blocks. Since you're using SATA drives, they should support S.M.A.R.T, but you might need to attach the drives to a SATA controller before the tool will 'see' these values. BTW, remember to upvote. –  Jesper Mortensen Apr 24 '11 at 16:16
add comment

You could try Hitachi's Drive Fitness Test tool, http://www.hitachigst.com/support/downloads/. Alternatively, you could make a few read/write passes with badblocks.

I don't know if you can use multiple D.F.T. at a time, but you can run multiple instances of badblocks.

Since the drives are large, a badblocks pass or two is going to take some time. Look at tweaking the block size and number of blocks setting (-b and -c, respectively) to get better performance.

Here is a sample command line:

badblocks -v -n -b 4096 -p 2 -c 8192 <device>
  • v - verbose output
  • n - non destructive read/write mode
  • b - size of blocks in bytes, default is 1024
  • p - number of passes
  • c - number of blocks to test at once
share|improve this answer
    
i guess multiple instances of badblocks (on the same drive) would cause a lot of head seeks, greatly increasing test time. Of course, if you can make each instance test a different drive, it would finish much sooner than one drive at a time. –  Javier Apr 21 '11 at 22:45
    
Given I'm not familiar with badblocks and can't sort the proper command set from the man page. Do you happen to know how specifically I'd be able to run it against all the disks at once? –  Garuda Apr 22 '11 at 2:50
1  
@Javier: I meant to use multiple instances of badblocks to test multiple disks. @Garuda: You have to run a separate instance for each disk you want to test. I do: badblocks -v -n -b 4096 -p 2 -c 8192 <device>. v - verbose output n - non destructive read/write mode. b - size of blocks in bytes, default is 1024. p - number of passes c - number of blocks to test at once It's helpful to run each one in a separate terminal so you can watch the progress of each one. 2 passes on 2TB drives is going to take quite some time, though. –  Kendall Apr 22 '11 at 15:01
    
thanks! The Hitachi Drive tool didn't see the disks which are presented via the Adaptec/IBM Serveraid 8k controller. So I'll use badblocks and the switches you've mentioned via different terminal sessions to do all the drives at once. I've done the 'Verify Disk' from the controller successfully on all the drives so I should be OK. Though from what I gather the verify disk just remaps bad blocks. –  Garuda Apr 24 '11 at 15:32
add comment

Linux's badblocks (from ext2/3/4 tools package) do this quite nicely.

Just run

badblocks -wvsb 4096 /dev/sda
to write 4 different patterns (all zeros, all ones, and two with zeros and ones) to drive to test it, destroying all data on the drive in the process or
badblocks -wvsb 4096 -p 3 /dev/sda
to do the above 3 times for through testing.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.