November 20, 200817 yr Hi all, Just wondering. Normally when I plug in a new drive in my unRAID, I just plug it in and hope it won't fail. I know this have been discussed before, that it would be wise to do a burn in test of the new hard drive before installing it in the unRAID server. So, do you do burn-in test when buying new hard drives? And if so, how do you do it? From a Windows (or other) machine with some kind of burn-in software or from unRAID directly? For how long do you test etc.? Cheers, Søren
November 20, 200817 yr I tend to buy harddrives in pairs, and came up with a burn-in process that I use. You can find a link in the "Best of the Forums" (see link in my sig). If you only have one drive, you could run the smartctrl long test. (See Troubleshooting page for instructions). I am sure there are tools on the market to burn in test a drive, but both of these are free.
November 20, 200817 yr Here's a tool which may help. A friend of mine uses this on every machine before it is deployed into production. You can select from a battery of tests. http://repository.slacky.eu/slackware-12.0/hardware/stress/1.0.0/ http://weather.ou.edu/~apw/projects/stress/ `stress' imposes certain types of compute stress on your system Usage: stress [OPTION [ARG]] ... -?, --help show this help statement --version show version statement -v, --verbose be verbose -q, --quiet be quiet -n, --dry-run show what would have been done -t, --timeout N timeout after N seconds --backoff N wait factor of N microseconds before work starts -c, --cpu N spawn N workers spinning on sqrt() -i, --io N spawn N workers spinning on sync() -m, --vm N spawn N workers spinning on malloc()/free() --vm-bytes B malloc B bytes per vm worker (default is 256MB) --vm-stride B touch a byte every B bytes (default is 4096) --vm-hang N sleep N secs before free (default is none, 0 is inf) --vm-keep redirty memory instead of freeing and reallocating -d, --hdd N spawn N workers spinning on write()/unlink() --hdd-bytes B write B bytes per hdd worker (default is 1GB) --hdd-noclean do not unlink files created by hdd workers Example: stress --cpu 8 --io 4 --vm 2 --vm-bytes 128M --timeout 10s Note: Numbers may be suffixed with s,m,h,d,y (time) or B,K,M,G (size). In order to test a drive, it has to be formatted and mounted. Then CD to the mounted drive In my example the drive is /dev/sdf1 mkdir /mnt/sdf1 mount /dev/sdf1 /mnt/sdf1 cd /mnt/sdf1 and run stress like this stress -d 1 -v (you can use any number of -d arguments) I use a bunch at times. I use the --hdd-noclean sometimes so I can make it create new files at every cycle. example: root@unraid /mnt/sdf1 #stress -d 5 -v stress: info: [3692] dispatching hogs: 0 cpu, 0 io, 0 vm, 5 hdd stress: dbug: [3692] using backoff sleep of 15000us stress: dbug: [3692] --> hoghdd worker 5 [3693] forked stress: dbug: [3692] using backoff sleep of 12000us stress: dbug: [3692] --> hoghdd worker 4 [3694] forked stress: dbug: [3692] using backoff sleep of 9000us stress: dbug: [3692] --> hoghdd worker 3 [3695] forked stress: dbug: [3692] using backoff sleep of 6000us stress: dbug: [3695] seeding 1048575 byte buffer with random data stress: dbug: [3696] seeding 1048575 byte buffer with random data stress: dbug: [3693] seeding 1048575 byte buffer with random data stress: dbug: [3694] seeding 1048575 byte buffer with random data stress: dbug: [3692] --> hoghdd worker 2 [3696] forked stress: dbug: [3692] using backoff sleep of 3000us stress: dbug: [3692] --> hoghdd worker 1 [3697] forked stress: dbug: [3697] seeding 1048575 byte buffer with random data stress: dbug: [3693] opened ./stress.mANRYh for writing 1073741824 bytes stress: dbug: [3693] unlinking ./stress.mANRYh stress: dbug: [3693] fast writing to ./stress.mANRYh stress: dbug: [3696] opened ./stress.3hw2Fg for writing 1073741824 bytes stress: dbug: [3695] opened ./stress.wiw2Fg for writing 1073741824 bytes stress: dbug: [3694] opened ./stress.xiw2Fg for writing 1073741824 bytes stress: dbug: [3696] unlinking ./stress.3hw2Fg stress: dbug: [3696] fast writing to ./stress.3hw2Fg stress: dbug: [3697] opened ./stress.YZdX3g for writing 1073741824 bytes stress: dbug: [3694] unlinking ./stress.xiw2Fg stress: dbug: [3694] fast writing to ./stress.xiw2Fg stress: dbug: [3697] unlinking ./stress.YZdX3g stress: dbug: [3697] fast writing to ./stress.YZdX3g stress: dbug: [3695] unlinking ./stress.wiw2Fg stress: dbug: [3695] fast writing to ./stress.wiw2Fg I do recommend taking a smartctl snapshot before and after. (plus the long test).
November 21, 200817 yr This would be another great feature for UnMENU! (in Joe's spare time of course!) You could install a new drive, start UnMENU, mount the drive, save and examine a first SMART report, run a SMART long test, check a new SMART report, run a Burn-in on it, and check a final SMART report, then unmount it. If still happy with the drive, assign it to the array. And integrate these ops with a user notes file (for a MyMain notes display), such as recording the Install Date and the initial and subsequent SMART reports, and tests run, and speeds determined.
December 18, 200817 yr I've created a tool to burn-in and pre-clear a drive. It is described here I think it does exactly what you wanted. You can set it for up to 20 burn-in (pre-read/clear/post-read) cycles. For a 1.5TB drive, 20 cycles would take about 14 days. (approx 17 hours for 1 cycle) Joe L.
Archived
This topic is now archived and is closed to further replies.