Advice on ways to burn in drives please

[TunaMaxx]

As discussed in another N00bs thread, I'm building another FreeNAS server. This one has four 2TB WD20EARX drives going into another HP Proliant N40L MicroServer with 8GB of RAM and an Intel EXPI9301CTBLK GB NIC. Problem is, the RAM and the add on NIC have been delayed.

In the meantime, I have the drives in and have started running SpinRite on 'em. SpinRite is predicting that it will take... 650 HOURS to complete ONE drive.

Since I'm sure that the remaining parts needed to build the FreeNAS server will arrive well before the 108 DAYS that SpinRite wants, can anyone offer advice on how I can use the time to burn in the drives?

 

[ProtoSD]

There was a time, a very brief time that I thought SpinRite had a purpose and maybe it does it some situations, BUT, burning in a hard drive with it wouldn't be my first choice. Give HDTune a try, there's a free version and a Pro version. There was/used to be a version on the Ultimate Boot CD, but it's not there anymore and it been updated. There is also a portable version you can run from USB. Here a link to their site:

http://www.hdtune.com/

 

[TunaMaxx]

Thank you for the comment.

Before I smartened up about redundancy and backups, SpinRite more than paid for itself a couple of times. However, I agree that it does seem a little long in the tooth these days, and it takes a long time to accomplish anything on today's giant drives.

I own an HD Tune Pro license, but I don't have any OS installed on this machine yet, so no go. That's why I dug out the old SpinRite CD as I could boot of it and let 'er rip. Except for the fact that the "rip" was more like an exceedingly slow, painful tear... ;)

While I'm waiting, I might do a temp Windows install on a drive in the 5th bay just for grins.

 

[survive]

Hi TunaMaxx,

If you are just looking to write a ton of data to the drives go grab a copy of Darik's Boot & Nuke at http://www.dban.org/ and let that run till your other parts get there.

-Will

 

[Milhouse]

I just use the Samsung HD diagnostic utility and run a single long test on each drive - takes about 18 hours for one of their 2TB drives on an N36L.

 

[TunaMaxx]

If you are just looking to write a ton of data to the drives go grab a copy of Darik's Boot & Nuke at http://www.dban.org/...

I tried that! The copy I have complained that it couldn't find any drives! Might try a newer version of DBAN and see if that helps.

I just use the Samsung HD diagnostic utility and run a single long test on each drive - takes about 18 hours for one of their 2TB drives on an N36L.

Whoa! That will be THREE DAYS to run all four... But I guess that's a lot of drive space, huh?

 

[Milhouse]

Whoa! That will be THREE DAYS to run all four... But I guess that's a lot of drive space, huh?

Unfortunately, yes, but I'd never put a new drive into use without at least checking every sector is readable. As an aside, considering how long it takes to test a single drive it's a wonder these drive utilities don't yet allow you to test multiple drives in parallel...

 

[jgreco]

Unfortunately, yes, but I'd never put a new drive into use without at least checking every sector is readable. As an aside, considering how long it takes to test a single drive it's a wonder these drive utilities don't yet allow you to test multiple drives in parallel...

The dban suggestion was pretty good because I believe it does do the drives in parallel.

But good tools to do some basic testing are at your fingertips, if you care to use them.

Beware, this will totally blank your drives! Open up a shell. For each of your drives, do a dd:

# dd if=/dev/zero of=/dev/ada0 bs=65536 &
# dd if=/dev/zero of=/dev/ada1 bs=65536 &
# dd if=/dev/zero of=/dev/ada2 bs=65536 &
# dd if=/dev/zero of=/dev/ada3 bs=65536 &

Now you're writing zeroes to all drives simultaneously. Use "iostat ada0 ada1 ada2 ada3 1" to see if they all seem to be writing at roughly the same speeds. This is a basic surface check of the disks for problems.

Wait until those writes are a good ways into the disks, percentage-wise. Then open another console login (alt-f2 or ssh in or whatever). Log in, and

# dd if=/dev/ada0 of=/dev/null bs=65536 &
# dd if=/dev/ada1 of=/dev/null bs=65536 &
# dd if=/dev/ada2 of=/dev/null bs=65536 &
# dd if=/dev/ada3 of=/dev/null bs=65536 &

Now you're reading each of the disks *while* writing. And, because you followed the instructions above and waited, the drives are madly seeking back and forth between the full-steam write operation above and the full-steam read operation here. If you have noisy drives, you will hear them. Transfer speeds will drop very substantially (unless you're on SSD). This is essentially a basic mechanical test.

Finally, *wait*. This is the important point. You want to wait and compare the final numbers. If the drives are identical, they should all show the same bytes transferred and very similar times. If you're using a mix of drives, the numbers should at least make sense and represent a full disk's worth of space, and times should also make sense when considering any differences in specs.

 

[Milhouse]

I think the manufacturer utilities also verify what has been written, but I'm sure that would be possible to replicate with dd also.

 

[jgreco]

The main problem with the manufacturer utilities is that it's never too clear what exactly each one does, since they all have some overlap but each also "do their own thing" too. Verifying what's written is a bit tricky. Fortunately, SATA includes error correction on data transfers, drives are intelligent and report errors without much effort, and filesystems like ZFS supervise it all with error detection at that level as well. I've gotten a lot less paranoid about that sort of thing over the years, because as a practical matter, it just doesn't happen anymore. The failures are generally very obvious when they happen. That doesn't mean that testing is worthless, but it's not likely to find a fault that wasn't already identified through other means. You could also modify my dd-athon above to strip NUL and "wc -c" (should return zero I would think) instead of writing to /dev/null, and there's probably a trivial way to write 0xff's to a drive at high speed, though I'm not thinking of it at this second. This might be more useful with SSD's than with HDD's.

 

[TunaMaxx]

...Now you're reading each of the disks *while* writing. And, because you followed the instructions above and waited, the drives are madly seeking back and forth between the full-steam write operation above and the full-steam read operation here. If you have noisy drives, you will hear them. Transfer speeds will drop very substantially (unless you're on SSD). This is essentially a basic mechanical test.

This is BRILLIANT! Thank you.