I'm building a new unRAID server, and am migrating from an older RAID-10 system. In order to speed up the initial transfer, I've not bothered adding a parity disk in yet.

 

Due to the fact that there's no parity, aside from verifying drive health, is there a need to run the preclear for disks added to the array? It would seem that unRAID doesn't clear disks when I add them to the array without the parity disk, and from my understanding of why you use preclear, etc, it makes sense to me that it's not necessary.

 

I figured I'd ask some of you more experienced folks before I copy 6TB of data across, only to clear the drives again.

I'm building a new unRAID server, and am migrating from an older RAID-10 system. In order to speed up the initial transfer, I've not bothered adding a parity disk in yet.

 

Due to the fact that there's no parity, aside from verifying drive health, is there a need to run the preclear for disks added to the array? It would seem that unRAID doesn't clear disks when I add them to the array without the parity disk, and from my understanding of why you use preclear, etc, it makes sense to me that it's not necessary.

 

I figured I'd ask some of you more experienced folks before I copy 6TB of data across, only to clear the drives again.

You are correct.  If there is no parity drive installed, it is useful only for verifying the drive's health. 

If you have no parity drive installed, there is no "clearing" step needed.

 

You should verify the files you migrate to the unRAID server with md5 checksums before deleting them from their original disks.  You should probably add the parity disk before performing that step as well so you know your only copy is protected.

 

Joe L.

 

 

You should verify the files you migrate to the unRAID server with md5 checksums before deleting them from their original disks.

Joe L. is there a recommended program to use for md5 checks?

Yeah, I have a little app I wrote that stores the MD5sums of all my archive files in a database, and then compares them periodically. I'm going to switch it over to the unRAID shares before I dismantle the old RAID-10 box.

 

Thanks for confirming my suspicions.

...program to use for md5 checks?

For unRAID, it's already in there: the command is called md5sum

For windows/Mac, check out HashTab.

 

You should verify the files you migrate to the unRAID server with md5 checksums before deleting them from their original disks.

Joe L. is there a recommended program to use for md5 checks?

There is one that comes with unRAID.  It is called

md5sum

 

log in via telnet then type

md5sum /mnt/user/ShareName/fileName

 

 

Joe L. is there a recommended program to use for md5 checks?

 

I'm sure someone has something nicer, but in a pinch, you could do something like this from the command prompt on the unRAID server:

 

find /mnt/disk1 -type f -print0 | xargs -0 md5sum > /boot/md5sums.disk1

 

Then, later, when you want to re-verify:

 

find /mnt/disk1 -type f -print0 | xargs -0 md5sum > /boot/md5sums.disk1.new
diff /boot/md5sums.disk1 /boot/md5sums.disk1.new

 

This presumes you can read a diff's output. However, if there is no output, it means nothing has changed. Hopefully someone else has something a bit prettier/easier.

 

I might give some thought to making my code a bit more portable, too.

Yeah, I have a little app I wrote that stores the MD5sums of all my archive files in a database, and then compares them periodically. I'm going to switch it over to the unRAID shares before I dismantle the old RAID-10 box.

 

Thanks for confirming my suspicions.

Once you know your hardware is working OK, the need to verify checksums pretty much goes away.  

 

The reason for the initial tests is easy.  We have seen bad network cards that flip bits, and bad disk controllers, an even bad disks, once it was only fixed by replacing the motherboard..  The most common problem is bad memory, or memory with the wrong voltage, timing, or clock speed settings.  Most of the time it showed as random parity check errors, but there were times it showed as un-playable files.

 

The periodic check you wrote is just a little insurance so if something is corrupted, at least you'll know it.

Thank purko, Joe L. and DocBlock for the recommendations.