Information about the problem of fast increasing Load_Cycle_Count with some disks is spread in the web. Here in this post I try to summarize the facts I have. I will update this post as new information becomes available.
If you think that anything should be mentioned here then please write a private message to me.
Summary of the facts:
- At least some versions of the Green Power disks from Western Digital seem to be switching between energy saving state (which starts after 8 seconds without access) and normal load operation when installed in a Unix/Linux based system.
- Affected disks show a fast growing load cycle count (LCC), which is a metric for how many times the drive unloaded its heads.
- When there is no access to the NAS (idle), the LCC increases between +50 and +120 per hour.
- As WD specified their disks for 300'000 LCC, the threshold will be reached within a few months. Maximum lifespan of affected disks might be shortened.
- If the NAS is under permanent load, LCC is not increased. So it is a problem in the idle state.
- It may be that disks mounted in an external case and attached via esata are not affected. But if these disks are used as internal disks with a logical volume on them, then they will show the high LCC as well.
- Not only Synology NAS are affected. Other Unix based NAS and Linux distributions seem to have the same problem.
- When the disks are installed in a windows system, there seems to be no problem.
- Not all combinations of disk version and NAS version seem to be affected by the problem. Up to now it is not known which combinations do have the problem and which do not.
- It seems that disks with version WD10EACS-00D6B0 (Nov 08) or later no longer show high LCC. Instead they show the START_STOP_COUNTER value as LCC. Question remains, if WD did really fix the problem or just mask it away by no longer showing the high LCCvalues to us.
- Western Digital has the position, that they do not support operation of their disks with other OS than Windows and Mac OS. Maybe you could add some pressure or take back the recommendation of theirs disks.
- The problem is discussed in many threads throughout the web. Just google for "high load cycle count" or similar terms.
- According to WD, setting the timeout of IntelliPark to 300 seconds should reduce the problem (in a Linux box with sync all 30 seconds that results in disabling the main feature of GreenPower technology). This workaround seems not to work for everybody (for me it does not).
Only 4 platter versions of the disk affected:
It seems that only 4 platter versions of the WD10EACS seem to be affected. All newer 3 platter versions of the WD10EACS are not affected. It guess that all WD10EADS (larger disk cache) are 3 platter versions and should not suffer from high LCC.
3 platter: WD10EACS-65D6B0, WD10EACS-00D6B0, WD10EACS-00D6B1 (show no high LCC but LCC equals SSC)
4 platter: WD10EACS-00ZJB0, WD10EACS-32ZJB0, WD10EACS-00C7B0 (show high LCC)
Reproduction of the problem:
- 1. Install the WD disk with green power technology into the NAS as disk1 or disk2 (internal!)
- 2. Write down the following SMART values: Power On Hours (POHstart) and Load Cycle Count (LCCstart)
- 3. Stop all activity on the NAS so the disks reach idle states often
- 4. After several hours write down again the following SMART values: Power On Hours (POHstop) and Load Cycle Count (LCCstop)
- 5. Calculate the LCC increase: LCCdeltaPerHour = ( LCCstop - LCCstart ) / ( POHstop - POHstart )
- 6. If your disk is affected, you will see LCCdeltaPerHour between +50 and +120 (--> you should post your values in the Experiment Thread by Franklin)
- 7. If your disk is not affected, you will see LCCdeltaPerHour between +0 and +10
- Good explanation of the head unloading/loading technique by Hitachi. I am not sure if WD uses exactly the same "ramp" technology.
- Potential explanation in another forum of what could be the reason for the high load cylce counts.
- Specification for WD Caviar GP disks
- Explanation of the WD Green Power Functions, the problem is probably due to "IntelliPark" feature
Many thanks for all the valuable help!