toki wrote:If you're using a WD Red drive or "green" type drive, someone posted this how-to that may help you and save the life of your hard drive.
As I noted above, some of the Blue drives are affected as well (recent Blue drives with 5400 spindle speed are effectively re-branded Greens). Consensus seems to be that if you have a 5400 RPM Blue, it has the head park timer issue. I can vouch for this, as I have seen it happen with 4TB Blue drives I own.
The source of the problem is Western Digital's attempt to make the device "more green" - use less electricity. One way to accomplish this goal is to park the heads on a plastic pad after eight seconds of no read/write requests instead of allowing them to float over the spinning platters of the hard drive. This adds up to 10,800 cycles each day.
You'd have to be pretty unlucky to get that many cycles though. You'd need to have something in your system that accesses the drive every 8.01 seconds like clockwork. If you're accessing it more frequently than that, the heads stay loaded; if you're accessing it less frequently, they stay parked between accesses.
If you do the math, data corruption will begin within 23.148 to 115.741 days if you are employing the hard drive on a heavily used server.
As noted above, on a
heavily used server the heads will stay loaded and the load/unload problem does not occur. It also isn't a hard-and-fast rule... exceeding the maximum number of cycles doesn't guarantee that corruption will occur. It just increases your risk of a failure.
That said, Linux seems to be a particularly problematic case. Something in the Linux file system logic apparently "touches" the disks about once a minute even if there is no user data access, resulting in hundreds of cycles per day even on an idle system.
Regular consumers will not notice read/write problems until later. Some WD drives reported 3,000 to 5,000 cycles per day. At this rate, the first instances of data corruption will begin within 83.33 to 250 days.
The last Blue I had where I forgot to disable the timer racked up way more than the rated number of cycles and still works just fine. It's luck of the draw. Saying "data corruption will begin within 83.33 to 250 days" is misleading; a more accurate statement would be "if you happen to have one of these worst-case workloads, your risk of premature drive failure may go up".
From my experience, early data loss will not be noticed by the average user. There are no signs of trouble if work files are not accessed, edited, and save. With numerous usages, lost sectors on the hard drive appear and indexes become corrupted. Then, damages become apparent. During bootup, Windows OS will begin employing Check Disk (chkdsk/f) to repair errors. Chunks of bad information get deleted and corrupted indexes are re-corrected during the process. Eventually, 50%-to-60% drive gets wiped out before the user realizes the problem. He accesses a file, and there is none. Using a file manager, further examinations reveal other missing data. This degradation takes time - months to a year depending on computer usage.
You're referring to bad/remapped sectors, caused by damage to the platter itself. Excessive head load/unload damages the heads, which will cause problems on newly written data as well. Two different failure mechanisms.
Nevertheless, six years of complains have forced the manufacturer to do something - provided a firmware fix. WDIDLE3.EXE software is used to reset the parking cycle to as high as five minutes.
The firmware supports values much higher than 5 minutes. The maximum possible value is in fact a bit more than 2 hours. I suppose it is possible that specific versions of WDIDLE3 may have artificially capped it at shorter values.
For normal users, this change brings down the parking cycle to 133 per day. This is within the industrial average. Most drives experience 10 to 200 per day and are rated around 600,000. WDIDLE3.EXE can also turn off head parking. Unfortunately, this is not recommended. Users have reported that drive speed was reduced to a crawl or exhibited read/write problems.
This is a symptom of other problems with the drive, not a disabled head park timer.
This solution is a masterpiece in public relations. Instead of deactivating or eliminating the eight second head parking cycle on newly manufactured drives, WD forces the user to make the firmware change after the sale. The process is not easy, and the company's website does not explain or provide any information - it provides just the software. The procedure requires unplugging all other devices that are connected to SATA ports and numerous resets to the BIOS. The computer must boot in DOS via a CD or USB 2.0 thumb drive and typing the required codes. Just finding the necessary software to create the booting device is a pain.
While I agree doing this on a Windows box is a bit of a PITA, it's not
that bad.
For Linux users, many distros provide a Linux version of the tool (typically called "idle3ctl") which can be installed directly from the distro's software repository. While it does require use of the CLI, it does not require any rebooting or use of removable media.
As a result, non-technical consumers will not do anything and allow their hard drives to malfunction. For the "techkies," it will take hours of research, internet searches, and trial-and-error. Hopefully, they will also be discouraged. In one stroke, the company has placated the critics and still maintain high sales volume.
Most non-technical consumers will not be affected, because they're not running Linux or some other workload that periodically touches the drive at a rate which will cause issues.
That said, it is still a good idea to increase the timer to 5 minutes (or more), unless you are REALLY prioritizing power usage above all else (in which case you should probably just shut the system off when you're not using it instead).