... you won't be surprised that I decided to purchase seven 4TB WD Red drives. Six would be used to populate the turbo-station itself, and the seventh would be a cold spare. I ended up purchasing the drives from Amazon, mostly because of the reports of lousy packaging at NewEgg.
The drives arrived in an unblemished outer box; the contents would shift when I shook the package. Inside the shipping carton were the seven individual drive boxes and several of the little air bags to occupy the empty space. Some settling had apparently occurred, but the drive boxes were all pristine.
- (20-20 hindsight. I should've purchased 8 drives. The shipping carton seemed to have been designed specially to hold 8 of the drive boxes, and had I ordered 8, the contents would not have shifted at all during shipping.)
Here's the identifying information for these first seven drives.
The right-most column displays the drives' idle3 value (that initially was misconfigured by WD ... as reported here in the QNAP forums and elsewhere). I used the Ultimate Boot CD (UBCD) to get this value. It contains v1.05 of the WDIDLE3.EXE and v5.20 of the DLGDIAG.EXE utilities. I tested each drive individually, connecting the HD to the same motherboard SATA port in turn. Whether it's the MB of the PC (an HP 6005 Pro MT) or the processor (AMD Phenom II X4 B95), the utility seemed to not be able to report the wdidle3 value (I presume) after the value had already been set to 'disabled.' The one drive that listed a value when queried -- it reported 300 -- indicates that the utility was working. Further, after I set this drive's value to 'disabled', power-cycled the machine, and then queried the drive, nothing was reported ... like the balance of these drives.
- (20-20 hindsight. I was lucky that I tested first, the only drive that reported a wdidle3 value. Otherwise I would've spent more time trying to create a bootable CD with v2.0 of the WDIDLE3 utility, which I downloaded from johnripper's post in one of the other threads. I spent several hours following the 'cookbook' for customizing the UBCD, but had no success ... so far. It's on my list of projects to pursue when I've got the time.)
The following table contains the results of the WD Data Lifeguard Diagnostics for DOS (DLGDIAG.EXE) Quick Test. These values were all harvested after restarting the PC (having completed using the idle3 utility), and then selecting the "Quick Test" option:
The following table contains the results of the DLGDIAG.EXE Extended Test. These values were all harvested after restarting the PC (having completed using the earlier Quick Test), and then selecting the "Extended Test" option. In all cases the time reported for the "Quick Test" (which runs automatically prior to the Extended Test) was the same as reported above.
The table says it all. Three of the seven drives did not complete the Extended Test. I called WD customer service, and was counseled to return the drives to the seller for an exchange. (The CS Rep was honest about doing a warranty exchange with WD -- and getting back re-certified drives -- and recommended the vendor exchange.) Prior to sending the drives back to Amazon, I ran the Extended Test on two of the 'bad' drives again. One of the drives completed the test successfully; the other failed again, this time about six hours into the test. I suspect that the program hangs when it identifies -- and marks/remaps -- a bad sector, as both of these re-tested drives sailed by the original stopping point.
No worries. Amazon's return procedures for defective products are straightforward enough. (I included a description of the Extended Test failure point in each box.)
After sending in the drives to be exchanged, I then started the long process of putting the turbo-station back into service using the four 'good' drives ... installing one drive first (under FW 3.8.1 that I had been running), then updating the FW to 4.0.3 (2013/09/12) automatically via the prompt in the QNAP web app. After validating successful operation, I added the other three drives, and started building a RAID6 volume ... to which I'd add two more drives once they arrived from Amazon.
To recap, of the seven drives I originally ordered, three had to be exchanged based on WD's recommendation. When I got the three newly exchanged drives, their packaging was slightly different. This time the boxes containing the drives were standard, fold-flaps-to-close boxes that were sealed with a large WD identification sticker and tape. The same clam-shell packaging inside, however.
The identifying information for the exchanged drives is provided in the table below. Of note, perhaps, is the fact that the drive dated 26 Nov 2013 did not have the anticipated "8 sec" (or other) wdidle3 value ... and that one of the 18 Jan 2014 drives setting was "300 sec". A recurring theme in the forum's discussions of WD 4TB Red drives and LCC/idle3 matters, is that there seems to be no consistent, constant pattern. Although the problem appears to be going away.
- (With more data ... hint, hint to the reader ... maybe a pattern or two would emerge.)
Here are the test results for the three exchanged drives. Two are in the turbo-station now, and the third is ready to replace one of the drives when necessary.
Wrapping up this story ...
After researching the drives -- which took considerable time -- I decided to document some of what I went through for others' potential benefit. If you decide to purchase WD 4TB Red drives, based on your operational requirements and your environment, I recommend that you:
- Check the drives' idle3 setting. Set it to disabled if not already so.
Do not place the drive into service if it does not pass the Data Lifeguard Extended Test. Rather exchange it at the seller for a different, brand-new disk.
Keep a record of all of the drives' identifying information for possible retrospective analysis.
And if you post a copy of the anonymized drive information here, as well as any unique behaviors/factors, maybe a pattern will emerge. The 'hive' can accomplish things that we, as individuals, could never accomplish.
Thanks for reading these posts.