S.M.A.R.T show’s high Load_Cycle_Count | Why and how to prevent the number from increaseing

hard-disksmartsmartctl

i just realized that some of my HDD's have a huge Load_Cycle_Count when reading out their S.M.A.R.T data. Some are short before failing and i am asking myself why this is the case and if there is anything i can do to prevent them from dying.

alex@ga-P55A-UD5:~$ sudo smartctl -a /dev/sdb
smartctl 6.5 2016-01-24 r4214 [x86_64-linux-4.4.0-142-generic] (local build)
Copyright (C) 2002-16, Bruce Allen, Christian Franke, www.smartmontools.org

=== START OF INFORMATION SECTION ===
Model Family:     Western Digital Caviar Green (AF)
Device Model:     WDC WD10EARS-00Y5B1
[...]
Vendor Specific SMART Attributes with Thresholds:
ID# ATTRIBUTE_NAME          FLAG     VALUE WORST THRESH TYPE      UPDATED  WHEN_FAILED RAW_VALUE
  4 Start_Stop_Count        0x0032   090   090   000    Old_age   Always       -       10281
  9 Power_On_Hours          0x0032   062   062   000    Old_age   Always       -       28456
193 Load_Cycle_Count        0x0032   001   001   000    Old_age   Always       -       611460

alex@ga-P55A-UD5:~$ sudo smartctl -a /dev/sdc
smartctl 6.5 2016-01-24 r4214 [x86_64-linux-4.4.0-142-generic] (local build)
Copyright (C) 2002-16, Bruce Allen, Christian Franke, www.smartmontools.org

=== START OF INFORMATION SECTION ===
Model Family:     Western Digital Caviar Green
Device Model:     WDC WD6400AADS-00M2B0
[...]
Vendor Specific SMART Attributes with Thresholds:
ID# ATTRIBUTE_NAME          FLAG     VALUE WORST THRESH TYPE      UPDATED  WHEN_FAILED RAW_VALUE
  4 Start_Stop_Count        0x0032   093   093   000    Old_age   Always       -       7615
  9 Power_On_Hours          0x0032   057   057   000    Old_age   Always       -       31743
193 Load_Cycle_Count        0x0032   053   053   000    Old_age   Always       -       442121

alex@silent-ssd:~$ sudo smartctl -a /dev/sdd
smartctl 6.5 2016-01-24 r4214 [x86_64-linux-4.4.0-142-generic] (local build)
Copyright (C) 2002-16, Bruce Allen, Christian Franke, www.smartmontools.org

=== START OF INFORMATION SECTION ===
Model Family:     Western Digital Green
Device Model:     WDC WD20EARX-00PASB0
[...]
Vendor Specific SMART Attributes with Thresholds:
ID# ATTRIBUTE_NAME          FLAG     VALUE WORST THRESH TYPE      UPDATED  WHEN_FAILED RAW_VALUE
  1 Raw_Read_Error_Rate     0x002f   200   200   051    Pre-fail  Always       -       0
  4 Start_Stop_Count        0x0032   098   098   000    Old_age   Always       -       2477
  9 Power_On_Hours          0x0032   085   085   000    Old_age   Always       -       11176
193 Load_Cycle_Count        0x0032   181   181   000    Old_age   Always       -       59646

Best Answer

My findings so far:

The Cause

Regarding to Western Digital and various websites 1, 2, 3, 4, 5, 6 the high number in S.M.A.R.T Attribute 193 Load_Cycle_Count is related to a technique introduced by WesternDigital named Intellipark.
Intellipark is implemented in some of their hard drive models, especially in their green series.
It is designed to reduce power consumption if the drive is not beeing used.
In some usecases, especially when combined with a Linux operating system, this intellipark-feature tends to shorten hdd's live.

Solutions

Western Digital explains it's not their features fault, it's the bad configured operating system and they give some advices on how to properly configure linux.
Western Digital also released a DOS tool to modify the intellipark-feature on some devices.
For the Linux platform Christophe Bothamy released idle3-tools to modify that intellipark-feature - big thank you from my site.
as mentioned in the comments below, hdparm -J does either modify the wd idle3 timer.

What I've done

Now I downloaded idle3ctl and turned off intellipark completely. Hopefully this will help to prevent the disks from failing quick. But anyway at least one disk is almost dead, regarding to S.M.A.R.T.

To disable the intellipark-feature i followed the idle3-tools instructions.

First I read out the idle3 timer value of this intellipark feature: sudo ./idle3ctl -g /dev/sdx

Than i disabled the timer sudo ./idle3ctl -d /dev/sdx

A power off/on cycle is necessary to take effect sudo hdparm -Y /dev/sdx

After that i rechecked the idle3 time and did the same after a reboot:

alex@silent-ssd:~/idle3tools/idle3-tools-0.9.1$ sudo ./idle3ctl -g /dev/sdd
Idle3 timer is disabled

Related Solutions

Linux – How to prevent the Linux kernel from waking a secondary HDD from sleep

since you only use the secondary hdd for backup, I would suggest telling fstab not to mount the drive automatically and to make a backup script that mounts the drive, makes the backup and unmounts the drive again.

example of the fstab line with the noauto option:

/dev/sdb1 /media/backup ext4 user,noauto 0 0

bash script for the backup would than begin with mount /media/backup and end with umount /media/backup

Hard-drive errors

From the smartctl man page:

The Attribute table printed out by smartctl also shows the "TYPE" of the Attribute. Attributes are one of two possible types: Pre-failure or Old age. Pre-failure Attributes are ones which, if less than or equal to their threshold values, indicate pending disk failure. Old age, or usage Attributes, are ones which indicate end-of-product life from old-age or normal aging and wearout, if the Attribute value is less than or equal to the threshold. Please note: the fact that an Attribute is of type 'Pre-fail' does not mean that your disk is about to fail! It only has this meaning if the Attribute´s current Normalized value is less than or equal to the threshold value.

If the Attribute´s current Normalized value is less than or equal to the threshold value, then the "WHEN_FAILED" column will display "FAILING_NOW". If not, but the worst recorded value is less than or equal to the threshold value, then this column will display "In_the_past". If the "WHEN_FAILED" column has no entry (indicated by a dash: ´-´) then this Attribute is OK now (not failing) and has also never failed in the past.

So according to the smartctl output section you have posted, your drive actually looks in good shape. However, that doesn't necessarily mean that there is not another problem.

Unfortunately the Unhandled sense code message does mean that something went wrong, but the kernel doesn't know what. You could try looking at the rest of the smartctl output to see if there is any thing wrong. There should be a part tha summarises the drive's overall health. You can get it on its own with the -H option.

If the drive supports self testing, you can start one with:

smartctl -t long /dev/sda

This starts one in the background, so you will have to keep checking for results. If the drive is not mounted, you can add the -C option enable captive mode which should take less time. A short test is also possible, but less thorough.

It is also a good idea to check physical connectors etc to make sure nothing as come loose - its an easy fix if it has.

Update

Wikipedia has a good reference for smart attributes. Note that the 'Better' column refers to the raw values in rightmost column of the output and not the normalised value at the start. Here is the part on 'Current Pending Sector' mentioned by frostschutz:

Count of "unstable" sectors (waiting to be remapped, because of unrecoverable read errors). If an unstable sector is subsequently read successfully, the sector is remapped and this value is decreased. Read errors on a sector will not remap the sector immediately (since the correct value cannot be read and so the value to remap is not known, and also it might become readable later); instead, the drive firmware remembers that the sector needs to be remapped, and will remap it the next time it's written. However some drives will not immediately remap such sectors when written; instead the drive will first attempt to write to the problem sector and if the write operation is successful then the sector will be marked good (in this case, the "Reallocation Event Count" (0xC4) will not be increased). This is a serious shortcoming, for if such a drive contains marginal sectors that consistently fail only after some time has passed following a successful write operation, then the drive will never remap these problem sectors.