July 24, 201114 yr I have 1TB of data to transfer to my data drive. Shall I transfer the data and THEN add a parity drive or assign a parity drive and then the data disk? I've heard its faster do get all my data to the data disk first so my write speeds aren't crippled by parity calculations but my only concern is the length of time the parity-sync will take with 1TB of data? Like will it be longer or shorter than if I were to assign the parity drive from the start?
July 24, 201114 yr I have 1TB of data to transfer to my data drive. Shall I transfer the data and THEN add a parity drive or assign a parity drive and then the data disk? It is safer to assign the parity drive and then start transferring data. I prefer the slow and safe method. I've heard its faster do get all my data to the data disk first so my write speeds aren't crippled by parity calculations but my only concern is the length of time the parity-sync will take with 1TB of data? Like will it be longer or shorter than if I were to assign the parity drive from the start? Parity calculation will take the same amount of time (roughly) no matter if the drive is full of data or completely empty. unRAID does not work on the file level, it works on the bit level so therefore does not truly care what is on the drive. To unRAID it is all 0's and 1's.
July 24, 201114 yr Author How long would the slow and safe method take? I think I'm going to simply copy 1TB of information from my windows PC to the unraid data share. Both are connected by ethernet to the modem (they're also side by side). What would you reccomend? I'm not deleting any data, it will still be on my other machine if something does happen... so to shave off a lot of hours, couldn't I just transfer the data and then do a parity sync and assign a parity drive? Will that drive, after the parity sync, have protection?
July 24, 201114 yr From what I've read on the forums, it's much faster to not assign a parity drive when initially transferring data. The problem is this is that if one of the hard drive crashes before you assign a parity drive, you lose all the data. So it's either you take a small risk to have faster data transfer at the risk of losing it (if you're unlucky enough for a drive to fail in a 24 hour timeframe) or you can be safe like prostuff1 suggested and use a parity drive when transferring.
July 24, 201114 yr Author I've never actually had a hard drive crash on myself. That would suck if it did with a brand new drive this quickly.
July 24, 201114 yr Author I've just started with teracopy and its going at 11MB/s. This is WITHOUT parity drive enabled. I'm guessing something is wrong. Both are connected via ethernet to my modem. My windows 7 PC on my network connections does say I'm connected @100mbps... could this be the cause for the slow speed? Should it be 1000? Is there a way to fix this?
July 24, 201114 yr I've just started with teracopy and its going at 11MB/s. This is WITHOUT parity drive enabled. I'm guessing something is wrong. Both are connected via ethernet to my modem. My windows 7 PC on my network connections does say I'm connected @100mbps... could this be the cause for the slow speed? Should it be 1000? Is there a way to fix this? 11MB/s is decent speed on a 100mbps connection. Something in your connected is slowing you down. Do both pc's have have GB connections? Is there a switch involved that is not GB? is the cable you are using CAT5e or CAT6
July 24, 201114 yr From what I've read on the forums, it's much faster to not assign a parity drive when initially transferring data. The problem is this is that if one of the hard drive crashes before you assign a parity drive, you lose all the data. So it's either you take a small risk to have faster data transfer at the risk of losing it (if you're unlucky enough for a drive to fail in a 24 hour timeframe) or you can be safe like prostuff1 suggested and use a parity drive when transferring. Actually, there is a bigger risk. The inability to read the data just loaded onto the newly installed data drive because of an unreadable sector. The disk does not need to crash to lose data, just have an unreadable sector... You'll not know of the issue until you go to calculate parity, and then parity will end up will a block of bad calculations. (in other words, if the data disk were to fail, parity would write all zeros in the block it could not read, and you will have potentially have a corrupted file.) If you had initially installed parity, before adding the data to the data drives, it would have the correct parity data. If you go to play a movie and the data disk sector is unreadable unRAID will automatically reconstruct it from parity and ALSO write it back to the failed drive so SMART firmware on the drive can re-allocate the sector and know the correct contents. In other words, if you install parity first, it *may take a bit longer to migrate data, but your data will be far less likely to be affected by an unreadable sector, AND, it in most cases, self-repairing as long as the parity disk is in pace and initial parity calculated. *Since most parity protected arrays can be written to at between 25 and 35MB/s, and you are currently limited to 11MB/s over your LAN because of a slow network, installing a parity drive would not slow you down. Your bottleneck is the LAN. Joe L
July 24, 201114 yr But if you preclear the disks first, won't that not happen because the preclear checks for bad/unreadable sectors?
July 25, 201114 yr When I started up my array I had 3TB to move. I thought the copy process would take forever, but honestly I just set it to copy with TeraCopy and Parity enabled and forgot about it. Of course I would check on it now and then, but I had TeraCopy set to verify everything after it copied it. It took a fair bit of time, but honestly after the copy I had a HUGE sense of relief knowing that TeraCopy was doing its checks and unRAID was doing its protection.
July 25, 201114 yr But if you preclear the disks first, won't that not happen because the preclear checks for bad/unreadable sectors? In theory, yes. In practice, pretty much. The preclear script does a great job of checking for hardware issues with your drives before you trust your data to them. However, it is still possible for a drive to fail even after passing preclear. You should carefully read your preclear report (which includes a SMART report) and decide for yourself if you trust the drive. If you need help interpreting the report, post in the preclear reports thread.
July 25, 201114 yr Author Well, I precleared my drive first, then using teracopy and CRC check, transferred the 1TB. Hopefully nothing goes wrong in terms of bad sectors being copied. I'm afterwards going to enable parity on the other drive and do a parity sync. Will my content then be protected after that?
July 25, 201114 yr Well, I precleared my drive first, then using teracopy and CRC check, transferred the 1TB. That is enough to make me feel comfortable, but of course everyone has different comfort levels. Hopefully nothing goes wrong in terms of bad sectors being copied. I'm afterwards going to enable parity on the other drive and do a parity sync. Will my content then be protected after that? Not quite. Once the parity sync completes without errors, then run a parity check. Once the parity check completes without errors, then your data will be protected. Don't erase your backups of your data until the parity check completes without errors. The parity sync makes sure the entire parity disk can be written to, whereas the parity check makes sure that the parity data can be read back. It is possible to have a disk that can write just fine but has tons of read errors, so it is important to check both. Since you already precleared the drive it is unlikely that you'll see this, but better safe than sorry.
Archived
This topic is now archived and is closed to further replies.