wsume99

I can't help but just be amazed at the poor quality of drives that are being shipped from OEMs. As long as they are all bad then I suppose it doesn't hurt any one of them too bad. Instead of fixing their drives (which would probably increase costs) the OEMs have just trained the market to do extensive testing on any new drive before using it.

Ok I am not linux savy so I need some help (aka hand holding). I have a C2SEE motherboard and 4-pin pwm fan connected. I ran pwmconfig and it was able to control my case fan. I had it perform a detailed correlation and it worked just fine. I can also control the speed by using the echo command... echo 0 > /sys/class/hwmon/hwmon2/device/pwm2 --> fan does not stop but slows to its lowest speed (680rpm) echo 255 > /sys/class/hwmon/hwmon2/device/pwm2 --> fan runs at max speed (1900 rpm) So at this point I'm assuming that means that all the drivers I need are already installed in the unRAID 4.7 kernel, correct? Thinking I was good to go I downloaded the unraid-fan-speed script and changed the user variables. I've attached my copy of the file. I then modified my go file to load the script into chrontab automatically. See attached. Rebooted my server and I got an error that says that sensors3.conf does not exist. I checked and it does not exist. I tried running sensors-detect and I basically get no response. I'm not really sure what that means. Perhaps I'm doing somethig wrong there. So I am not sure what to do at this point. Do I need a sensors.conf file for this to work properly? Any help would be appreciated. unraid_fan_speed.txt go.txt

LOL - That's because they are all out protesting and rioting in the streets. But don't worry my German friend, the Americans will be out there as well in a few years (once this massive debt we've run up comes due). :'(

Well I am by no means an expert but there are lots of I/O errors in there and it looks to me like at some point unRAID had to reset the link to the drive because of this. Here are some of the lines from the report ... Oct 29 02:47:09 Titan kernel: ata5.00: failed command: CHECK POWER MODE Oct 29 02:47:09 Titan kernel: ata5.00: cmd e5/00:00:00:00:00/00:00:00:00:00/40 tag 0 Oct 29 02:47:09 Titan kernel: res 40/00:00:00:00:00/00:00:00:00:00/40 Emask 0x4 (timeout) Oct 29 02:47:09 Titan kernel: ata5.00: status: { DRDY } Oct 29 02:47:09 Titan kernel: ata5: hard resetting link Maybe you have a bad power connection and/or SATA cable. Check the connections and cables. I'd recommend switching them with a known good power connector and SATA cable. Perhaps use ones that are connected to another drive that is working fine now. Then try the precelar again.

I've never had a WD Green drive with that slow of a read rate. I don't think that running 4 drives at a time would cause this. Is this a WD EARS drive? If so, did you put the jumper on pins 7 & 8?

Well the third run is complete and there were no additional errors reported - so a total of four sectors had errors. Ironically the current pending sector count went down from 8 to 2. Still no reallocated sectors. Maybe my prayers to the HDD gods are being answered. I swapped the power connection with one from another drive just to see what happens. I also checked and I don't know how but the IDLE3 timer was set back to the factory default of 8 secs. That would explain why the load cycle counts were incrementing between preclear cycles. I again disabled it using WDIDLE3 /S0 command. Rebooted and verified that head parking was indeed disabled using WDIDLE3 /R and it was. Perhaps I do have a power issue as the load cycle count went up by two during the last preclear cycle. On the previous two runs it only changed by one, which is what I would expect. I launched another preclear cycle and I'm interested to see what happens with this one. I'll find out in about 30 hours.

I'm pretty sure, in fact I'm positive, that I did a power cycle. I know I did because I put the DOS bootable USB drive in the place of my unRAID USB drive to change the setting. After changing the IDLE3 setting I powered down the server, swapped USB drives, then powered up in unRAID. But just to be sure I'm going to check the setting again tonight. If that doesn't work I'll try the WDIDLE3 /D command and see how that works. I tried that the first time but it did not report that head parking was disabled (as the command is supposed to) just that it was a really long time (~64 minutes).

I went back and did some more analysis of my syslog. On the first preclear run all of the errors were isolated to two sectors (1682918047 & 1683029711). It's a little strange that the post-clear SMART report showed a raw value of 3 current pending sectors. The second preclear run produced errors on five sectors (1682918047, 1683018743, 1683029711, 1683035192, and 1683062151). So the two suspect sectors from the first pass repeated and three new ones were added. This time the post-clear SMART report showed a raw value of 7 current pending sectors. Again not sure why it saying 7 when there were errors on only 5. The third preclear run is not completed yet (about 50% thru the post read process) but so far there were errors reported against four sectors (1683018743, 1683035191, 1683062152, and 1683090639). No errors reported yet against the repeats from the first two runs, maybe they've been reassigned. Also one repeat of a new sector from the second run and then three new sectors. But the funny thing is that the SMART report at the beginning of the run showed 8 current pending sectors when it only reported 7 at the end of the last run. How can that be? This drive is not assigned in my array so it should not be read from, so how could more pending sectors be identified between preclear runs? Another strange occurence. Before starting the precelar process I used the WDIDLE3 utility to disable the head parking feature on this drive. I used the WDIDLE3 /D command and got a response that the head park time was set to something like 64.7 minutes - IIRC. Then I tried the WDIDLE3 /S0 command and got a response that said head parking was disabled. Well looking at the results it is clearly not disabled. The load cycle count started the first run and 8 and ended it at 9. In the hour and 25 minutes betwen preclear runs the load cycle count went from 9 to 96. It ended the second run at 97. In the 3 hours and 17 minutes between the 2nd and 3rd runs it wend from 97 to 295. So clearly it has not been disabled eventhough it reported that it was. I'm really beginning to not like this drive.

Good point Joe L. I'll try another connector after the third cycle is finished. Although I'm not holding my breath as the power connector that is currently connected to that drive was previously connected to another drive which did not have any SMART problems at all. But I suppose that there is a chance it could be flaky so better safe than sorry. Should I switch the sata cable also? The sata cable I'm using is new so it could be bad as well. Could it cause the types of errors I'm seeing?

Do you mean try a different sata power connector on my current power supply or an entirely new power supply?

Here is the syslog from the second cycle. syslog-2ndcycle.txt

I'm currently running my third preclear cycle on a new WD20EARS (about 60% complete on the preread). The raw values for raw read error rate and current pending sectors are increasing. As well you can see a lot of reported read errors in the attached syslog, which I assume is driving the changes in the SMART reported raw values. FYI - the attached syslog only includes the results from the first preclear because there were so many errors that the file size was too large to be attached. I'll attach the results from the 2nd cycle on another post. I guess that's not a good sign either. But the changes are limited to only the raw values and not the normalized values. I'm wondering what the community thinks about the drive so far? Should I consider a RMA for this drive or is it too early to tell? It's not the fact that there are errors being reported that bothers me as much as the fact that they are increasing. Doesn't give me a lot of confidence that the drive will last. syslog-1stcycle.txt

My background is in reliability so I do know a thing or two about the bathtub curve. Many manufacturers will do ESS (Environmental Stress Screening) or HASS (Highly Accelerated Screening) on their products before shipping them. However since hard drives are a commodity I doubt that any of them do it. Maybe on their enterprise products which carry a higher price. The intent is to stress the products so that latent mtg. defects will be found prior to operational use. Essentially they truncate the front part off the bathtub curve so that all the customer is exposed to is a constant, very low (hopefully) failure rate for many years prior to climbing up the other side of the bathtub curve which would be associated with failures due to wearout. Your preclear process is essentially a form of HASS. We're stressing the drive to determine if there are any defects - the thought being that if it lasts X number of hours without failure (i.e. SMART errors) then it should last a long time. The only problem is that most companies tailor the length of their ESS or HASS tests based upon their knowledge of the bathtub curve specific to their device. Since we lack that knowledge all we can do is guess. I'd say that something like 50-100 hours would be reasonable, so the number of recommended cycles would vary depending upon the size and speed of your drive. You are right and like I said above, stressing the drive will get you into the constant, very low failure rate portion of the bathtub curve. There is no such thing as a failure rate of zero. But you can always just skip the several cycles of preclear and install your drives fresh out of the box. Let me know how that works out for you.

I don't think I've seen this question answered yet in this thread... How many times should preclear be run on a new drive? Should I run it once and if nothing unusual pops up in the SMART reports then stasrt using it. If the drive is going to be problematic does it usually show signs from the very beginning or are more cycles needed to weed out the bad drives before putting them into service?