October 24, 201312 yr So I finally got my hardware and built my server and now I've begun the installation/configuration. Of course I get to the recommended "preclear" section and think "ugg... that sucks". Anyway, better safe than sorry, right? So I start the task. Now I'm wondering... is my setup particularly fast or did I miss something or does the process dramatically slow down later on? Reason I ask, is I saw the table of times for what to expect and what I'm seeing is nowhere near as slow as that. I currently have 3 Seagate 2TB NAS drives simultaneously preclearing. Its been three and a half hours and its now 76% done. That means it will be done one cycle in 4:20... nothing even close to the 24+ hours shown on that list for similar drives. Does this mean I can expect three cycles to be done in roughly 13 hours? Or am I in for a rude surprise?
October 24, 201312 yr It will slow down towards the end of the drive and the last read pass is much slower (about 1/2 the speed), as it's a random access test. For me, 4TB drives take about 48 hours, sometimes a bit less. If you use unMENU, the speeds displayed there are more accurate.
October 24, 201312 yr Author can you give me a tip on what you mean about unMENU? I did install it... as per the configuration wiki suggestions... but I don't know how to "use" it to see preclear times. Thanks.
October 24, 201312 yr Preclear also goes through multiple phases, it reads the entire disk, writes zeros to the entire disk, and then reads the entire disk again, so you may be seeing 76% on the initial read of the disk, as it tracks the process through each section, not the overall process
October 24, 201312 yr It will slow down towards the end of the drive True, sometimes to half of the speed on outer cylinders where data density is higher.and the last read pass is much slower (about 1/2 the speed), Trueas it's a random access test. False, it is a full read AND verify of the zeros written. It is not just a random access test.
October 24, 201312 yr Author I'm now at 95% @ 4.5 hours. Again, that's 3 drives simultaneous. I just hope I'm not wasting this time as I've missed some step and its only doing part of the job. The command I entered was: ./preclear_disk.sh -r 65536 -w 65536 -b 2000 -A -c 3 -M 4 /dev/sdX where X is substituted for the 3 drives of course Assuming that's OK, let me ask you this: Can I expect the 3 cycles to be roughly the same? I mean say this one finishes in 5 hours or whatever... does that mean I'm looking at 3x5=15 hours? Or not?
October 24, 201312 yr Author Also, just a curiosity, is it "normal" for one drive to overtake the others? They're identical drives, but now I see that the one I started 2nd (~3 minutes after the first) is running 3 degrees hotter and has now completed 97% vs 95% for the one I started first.
October 24, 201312 yr I'm now at 95% @ 4.5 hours. Again, that's 3 drives simultaneous. I just hope I'm not wasting this time as I've missed some step and its only doing part of the job. The command I entered was: ./preclear_disk.sh -r 65536 -w 65536 -b 2000 -A -c 3 -M 4 /dev/sdX where X is substituted for the 3 drives of course Assuming that's OK, let me ask you this: Can I expect the 3 cycles to be roughly the same? I mean say this one finishes in 5 hours or whatever... does that mean I'm looking at 3x5=15 hours? Or not? It sounds as if it is nearly done with the "pre-read" of the first cycle. It will next write zeros, and then after that, verify that zeros were written. Your command syntax looks perfectly fine. I'm guessing about 20+ some hours per cycle.
October 25, 201312 yr Author gotcha. Yeah, I thought 95% meant 95%! I figured, OK the last 5% might take a long time... but its still 95% done. Guess this suffers from the same kind of time keeping / progress bars of Microsoft lol 3 days to prepare a servers disks... I dunno, but I guess I'm not in a hurry. Should I be at all worried about temps? Its obviously warning me since they are consistently above 40 degrees celcius (its highlighting it). 3 days at "high" temps... is that a problem?
October 25, 201312 yr gotcha. Yeah, I thought 95% meant 95%! I figured, OK the last 5% might take a long time... but its still 95% done. Guess this suffers from the same kind of time keeping / progress bars of Microsoft lol 3 days to prepare a servers disks... I dunno, but I guess I'm not in a hurry. Should I be at all worried about temps? Its obviously warning me since they are consistently above 40 degrees celcius (its highlighting it). 3 days at "high" temps... is that a problem? NO -- it's NOT 95% done ==> it's 95% done with the pre-read pass. After that (as Joe already outlined) it will do the actual pre-clear (which will take roughly the same amount of time as the pre-read); and then it will do the post-read, which not only reads and validates all of the data, but also does it with a lot of seeks to thoroughly test the positioning mechanism ... the post-read typically takes as long as the first two passes combined. Based on your timing through this point, I'd guess 20-22 hours total for your drives.
October 25, 201312 yr NO -- it's NOT 95% done ==> it's 95% done with the pre-clear pass. NO -- it's NOT 95% done ==> it's 95% done with the pre-READ pass.
October 25, 201312 yr Whoops -- I knew that ... my fingers didn't cooperate with my brain !! Note I did say the NEXT pass was the pre-clear pass ... and referred to the pre-read in my comments about the timing [i edited the post to correct it]
October 25, 201312 yr Author So I'm looking at some 60 to 66 hours total? lol. Is this something unique to unRaid? Seems a bit... well... excessive. I also have to wonder if its not a bit, perhaps, counterproductive? I read somewhere that people found errors only after the 3rd cycle... is it not possible that burning the HD so hard for so many constant hours CAUSED the breakdown and errors? Of course, that's always been the argument against stress testing anything (that the test itself causes premature failure of an item/device that otherwise may have had a perfectly normal life under typical conditions). Considering I'm not even sure at this point if unRaid is what I'll ultimately end up using... I'm now regretting the 3 cycle option. Do I have an opportunity at all after the 1st cycle to halt safely (and without unRaid feeling the need to re-do the process because a partially complete cycle)?
October 25, 201312 yr Running three pre-clear cycles will not increase the likelihood of a future failure. What it will do (in many cases) is to identify those drives which are going to fail early. This type of failure is known as infant mortality. You really want these drives to fail in the pre-clear process and not in a week or three when you have loaded them with data! Fro more information, Look at 'Bathtub curve' on Wikpedia or google 'bathtub failure mode'
October 25, 201312 yr Author Yeah, I'm familiar with the concept... but its not as though its an incontrovertible truth. There are two sides to the debate (and yes, its a debate). I'm not entirely sure how it applies to HDDs exactly, but in general: Side 1 says you discover problems that are inevitable; Side 2 says those problems may never have occurred if you didn't stress it trying to see if it would fail. Again, I don't know about HDD specifically, but some [things] have a voided warranty by stressing because its beyond "typical use", so proving that it wasn't a Grade-A example only costs you money. Anyway, I'm not arguing. I get the concept, and I'm going to continue based on recommendations I've read here. Signing off for the next 3 days or so
October 25, 201312 yr Preclear does not "stress" the drive, it reads and writes every spot that will be used to store data or rebuild data on another failed drive in the array. Reading and writing data is the basic function of a hard drive, so by definition it's not stress, it's normal use. In the vast majority of consumer drives, a large percentage of the capacity of the drive is never used. Unraid, however, requires that the whole drive be ok to rebuild another failed drive, so it is wise to test it before you trust it. Drives that fail the preclear likely would have lived much longer in a lightly used windows box, but that doesn't mean the drive was good.
October 25, 201312 yr It will slow down towards the end of the drive True, sometimes to half of the speed on outer cylinders where data density is higher.and the last read pass is much slower (about 1/2 the speed), Trueas it's a random access test. False, it is a full read AND verify of the zeros written. It is not just a random access test. Sorry, I was referring to this from your Preclear thread: When pre/post reading the disk, I intersperse reading the beginning block, random blocks of data, the linear set of blocks of the entire drive, and the last block on the device. I purposely keep the disk head moving a LOT more than if just reading each block in turn. This is to identify hardware that is marginal. If your disk or cables, or controller, or power supply cannot cope with constant activity... you probably want to know it before you assign the disk to a spot in your array. I took that to mean the post-read read the whole drive, just not in a linear fashion, hence the longer time taken. I didn't realise the pre-read also did that. Why does the post-read take so much longer than the pre-read?
October 25, 201312 yr Joe can confirm, but I believe you understand it correctly. The pre-read simply reads the entire drive to confirm all is readable; the subsequent pre-clear pass writes all zeroes and the pre-clear signature. These take approximately the same time, as they're simply linear passes through the disk. Then the post-read does a complete read, but NOT simply linear -- it's designed to exercise the seek mechanism enough to have high confidence that all is working well. That's why the final phase takes so much longer than the initial pre-read [in fact, the post-read takes longer than the first two phases together]. Joe doesn't like the characterization "random" -- and I'm sure he's correct, it's not actually random; but it's certainly not linear either [since he wrote it, I'm sure he could outline the algorithm ... but it's not important => the key is that it does indeed read every sector -- just not in order].
October 25, 201312 yr It was my belief that the post read was so slow because it was combining a sequential read and check for zeros with a random seek to read sectors that may or may not have already been read. So in essence at the end of the process many sectors have been read twice. Once on the sequential read and check for zeros plus any sectors that are read on the random seeks. d#$ - can't spell "it" fixed now.
October 25, 201312 yr Author Day Two: Alright, the total times for the first cycle went as follows: ========================================================================1.13 == == Disk /dev/sdc has successfully finished a preclear cycle == == Finished Cycle 1 of 3 cycles == == Using read block size = 65,536 Bytes == Last Cycle's Pre Read Time : 4:54:28 (113 MB/s) == Last Cycle's Zeroing time : 4:07:33 (134 MB/s) == Last Cycle's Post Read Time : 9:01:30 (61 MB/s) == Last Cycle's Total Time : 18:04:33 == == Total Elapsed Time 18:04:33 == == Disk Start Temperature: 34C == == Current Disk Temperature: 39C, == == Starting next cycle == ========================================================================1.13 ========================================================================1.13 == == Disk /dev/sdd has successfully finished a preclear cycle == == Finished Cycle 1 of 3 cycles == == Using read block size = 65,536 Bytes == Last Cycle's Pre Read Time : 4:58:17 (111 MB/s) == Last Cycle's Zeroing time : 4:13:05 (131 MB/s) == Last Cycle's Post Read Time : 9:09:20 (60 MB/s) == Last Cycle's Total Time : 18:21:43 == == Total Elapsed Time 18:21:43 == == Disk Start Temperature: 33C == == Current Disk Temperature: 39C, == == Starting next cycle == ========================================================================1.13 ========================================================================1.13 == == Disk /dev/sdb has successfully finished a preclear cycle == == Finished Cycle 1 of 3 cycles == == Using read block size = 65,536 Bytes == Last Cycle's Pre Read Time : 4:59:19 (111 MB/s) == Last Cycle's Zeroing time : 4:13:42 (131 MB/s) == Last Cycle's Post Read Time : 9:11:15 (60 MB/s) == Last Cycle's Total Time : 18:25:17 == == Total Elapsed Time 18:25:17 == == Disk Start Temperature: 32C == == Current Disk Temperature: 35C, == == Starting next cycle == ========================================================================1.13 Interesting thing (to me, who's new to this) is the difference in times between the drives. sdb was the first drive to start but the last to finish - by quite some time (in absolute terms, anyway... % is marginal). What makes sdc so "fast"? Or are the other two "slow"? sdb also ran a significant degree cooler compared to the other two.
October 25, 201312 yr Your times are actually very close -- it's normal for their to be differences. I've seen as much as a couple hours difference on large (4TB) drives. Worry about the results -- not the times
October 26, 201312 yr Author Nice to see the 2nd cycle was faster than the first by some 5 hours... I'm assuming that's normal. ========================================================================1.13 == == Disk /dev/sdc has successfully finished a preclear cycle == == Finished Cycle 2 of 3 cycles == == Using read block size = 65,536 Bytes == Last Cycle's Pre Read Time : 4:54:28 (113 MB/s) == Last Cycle's Zeroing time : 4:07:19 (134 MB/s) == Last Cycle's Post Read Time : 9:03:26 (61 MB/s) == Last Cycle's Total Time : 13:11:45 == == Total Elapsed Time 31:16:18 == == Disk Start Temperature: 34C == == Current Disk Temperature: 39C, == == Starting next cycle == ========================================================================1.13 Can I expect even faster for the 3rd?
Archived
This topic is now archived and is closed to further replies.