laptop harddrive Load_Cycle_Count issue

[ubuntu_demon]

Don't apply any unofficial ugly fixes unless you understand what you are doing and you understand how to revert. Only apply this fix if you are heavily affected. After applying this fix keep an eye on your Load_Cycle_Count and on your harddrive temperature and make sure it remains below the maximum temperature specification of your harddrive. Also don't forget that having your harddisk head park protects your harddrive if you experience any bumps (which is especially nice if you are on the road and therefor probably working on battery). Everything you do is on your own risk.

Please give me feedback so I can improve this post.

Not everyone is affected but here's a little bit of background.

A lot of laptop drives are affected. Almost no desktop drives are affected except :
* possibly some "very green" drives which use very aggressive power management
* possibly some external drives which use laptop drives.

If your harddrive spins down and spins up again your Load_Cycle_Count increases by one. If your harddrive head parks and unparks again your Load_Cycle_Count increases by one. This is done to save power. Laptop harddrives can handle a limited number of Load_Cycles. Most of harddrives can handle at least 600.000 Load_Cycles but you should look it up for your specific model.

Laptop harddrives use more aggressive power management than desktop harddrives. Some laptop harddrives are using very aggressive power management (set by the laptop harddrive firmware or possibly by some laptop BIOS'es). Aggressive power management will cause your laptop's harddrive head to park quickly. Disk activity will unpark it again.

No disk activity at all will keep it parked. Constant disk activity won't park your harddrive head but this also causes wear and tear (MS Windows might be doing this).

Regular disk activity with periods of no disk activity such as caused by ext3 journalling (which is safer for your data) or such as caused by firefox will park and unpark your harddrive head often. This combination of aggressive power management and regular disk activity is causing too rapidly increasing Load_Cycle_Counts for some people.

Look up how many Load_Cycle_Counts your harddrive can handle (most harddrives can handle 600.000 Load_Cycles but be sure to look it up). Calculate the average difference in Load_Cycle_Count per day. Now calculate what your Load_Cycle_Count will be in three years of harddrive use to determine whether you need to apply the ugly fix. This is explained inside the unofficial ugly fix.

So the causes for the problem are as follows :
* a lot of laptop harddrive firmwares set too aggressive power management settings
* this is probably not a problem for windows because there is probably almost constant disk activity (almost no head parks) so probably laptop harddrive manufacturers don't take this problem seriously
* the average linux laptop doesn't access the disk as often as windows but accesses it too often for a nice and long head park.

The result for some laptop harddrives :
* increasing the Load_Cycle_Count beyond the specifications and therefor risking an early dead.

What we can do now :
* watch our Load_Cycle_Count and harddisk temperature
* we can report unnecessary disk activity bugs which will make our harddrive heads park longer
* for those of us who are heavily affected : the ugly fix is to disable harddrive power management while on AC (no protection from bumps,increased heat) and enable harddrive power management while on battery (increased battery life,protection from bumps, less heat, fast rising Load_Cycle_Count)

The future :
* when linux becomes bigger and bigger on the laptop harddrive manufacturers will take this problem seriously
* flash storage is the future for laptop harddisks and doesn't have this problem (no moving parts)

Unofficial Ugly Load_Cycle_Count Fix for Gutsy
http://ubuntuforums.org/showpost.php...46&postcount=2

Unofficial Ugly Load_Cycle_Count Fix for Hardy
http://ubuntuforums.org/showpost.php...46&postcount=3

Idea #288: Fix Hard Drive Load Cycle Problem in Laptops
* http://brainstorm.ubuntu.com/idea/288/

If you think Load_Cycle_Count didn't rise that quickly before :
* See whether your swap is used (if there's a lot of swapping going on you might want to buy more ram): $ free -m
* Try disabling tracker (system->preferences->search and indexing)

More information :

The bug
People should also consider reading the bug. It contains a lot of noise but some posts are very informative such as those by Bart Samwel who maintains laptop-mode-tools and acpi-support in Debian.
https://bugs.launchpad.net/ubuntu/+s...ort/+bug/59695
https://bugs.launchpad.net/ubuntu/+s...ort/+bug/17216 (same story here. this was the bug while 59695 was slashdotted)

How to help finding disk activity bugs with blktrace (you can also use lm-profiler in addition) :
http://ubuntuforums.org/showpost.php...&postcount=375
http://ubuntuforums.org/showpost.php...&postcount=479

Possible disk activity bugs :
* the commit interval for the ext3 filesystem should be higher than 5 seconds for laptop users by default (at least while on battery)
https://bugs.launchpad.net/ubuntu/+s...ux/+bug/160448

* ext3 partitions should be mounted with noatime or relatime
https://bugs.launchpad.net/ubuntu/+s...ux/+bug/160450

* acpid : Log output far too verbose
https://bugs.launchpad.net/ubuntu/+s...pid/+bug/31512

* liferea might cause unnecessary disk activity
https://bugs.launchpad.net/ubuntu/+s...ea/+bug/160460

* thunderbird might cause unnecessary disk activity
https://bugs.launchpad.net/ubuntu/+s...rd/+bug/160466

* tracker : the index delay should be set to a higher value for laptop users
https://bugs.launchpad.net/ubuntu/+s...er/+bug/160468

* firefox might cause unnecessary disk activity when going to a new website
https://bugs.launchpad.net/ubuntu/+s...ox/+bug/160513

* hddtemp might cause unnecessary disk activity
https://bugs.launchpad.net/ubuntu/+s...mp/+bug/160621

* tracker and cronjobs (updatedb, update-notifer,...) fight for the hard disk
https://bugs.launchpad.net/ubuntu/+bug/152051/

* Don't install slocate by default on Desktops
https://bugs.launchpad.net/ubuntu/+bug/140493/

* Firefox 3 keeps forcing disk to spin up when browsing because its sqlite storage calls fsync() for every recorded entry
https://bugs.launchpad.net/ubuntu/+s...0/+bug/221009/

* liferea is slow on updating feeds if you have lots of feeds. multiple threads are needed for updating feeds.
https://bugs.launchpad.net/ubuntu/+s...ea/+bug/227976

Other related bugs :

laptop-mode-tools uses hparm -B 255 instead of 254 please sync laptop-mode-tools from Debian to fix this
https://bugs.launchpad.net/ubuntu/+s...ls/+bug/172282

hdparm's feedback about -B values is misleading
https://bugs.launchpad.net/ubuntu/+s...rm/+bug/172287

using laptop-mode causes system hangs for some people
https://bugs.launchpad.net/ubuntu/+s...ls/+bug/172293

laptop-mode should default to *always* use relatime for ext3 partitions while keeping the CONTROL_NOATIME option
https://bugs.launchpad.net/ubuntu/+s...ls/+bug/172301

scripts in /etc/pm/power.d should be called after resuming/ thawing
https://bugs.launchpad.net/ubuntu/+s...ls/+bug/235105

Please give me feedback so I can improve this post.

Don't apply any unofficial ugly fixes unless you understand what you are doing and you understand how to revert. Only apply this fix if you are heavily affected. After applying this fix keep an eye on your Load_Cycle_Count and on your harddrive temperature and make sure it remains below the maximum temperature specification of your harddrive. Also don't forget that having your harddisk head park protects your harddrive if you experience any bumps (which is especially nice if you are on the road and therefor probably working on battery).Everything you do is on your own risk.

[ubuntu_demon]

Unofficial Ugly Load_Cycle_Count Fix for Gutsy

Don't apply any unofficial ugly fixes unless you understand what you are doing and you understand how to revert. Only apply this fix if you are heavily affected. After applying this fix keep an eye on your Load_Cycle_Count and on your harddrive temperature and make sure it remains below the maximum temperature specification of your harddrive. Also don't forget that having your harddisk head park protects your harddrive if you experience any bumps (which is especially nice if you are on the road and therefor probably working on battery).Everything you do is on your own risk.

Please read why I'm recommending this solution if you are heavily affected :
http://ubuntuforums.org/showthread.p...55#post5038155

Now to determine whether you actually suffer from this problem :

To query S.M.A.R.T. data you need to install smartmontools :

$ sudo aptitude install smartmontools

If smartctl says your drive isn’t healthy anymore (for any reason) your harddrive might start dying soon.

$sudo smartctl -H /dev/sda

Now check how fast your Load_Cycle_Count is increasing (the last number is your Load_Cycle_Count) :

$ sudo smartctl -a /dev/sda | grep Load_Cycle_Count

Look up how many Load_Cycle_Counts your harddrive can handle (most harddrives can handle 600.000 Load_Cycles but be sure to look it up). Calculate the average difference in Load_Cycle_Count per day. Now calculate what your Load_Cycle_Count will be in three years of harddrive use to determine whether you need to apply the ugly fix.

The smartctl values aren’t always easy to interpret. If the Load_Cycle_Counter value behaves as a counter and increments by steps of 1 and is below impossible to reach values it’s probably the right number.

You can also look at “WORST” and “THRESHOLD” (|more instead of |grep to easily see which value is “WORST” and which value is “THRESHOLD”) :

$ sudo smartctl -a /dev/sda | more

If WORST is lowering (too fast) than you might be suffering from this problem. You can roughly calculate how long it will take for WORST to reach THRESHOLD if you keep watching those values daily/weekly. The closer WORST is to THRESHOLD the likelier it is for your drive to die from a high Load_Cycle_Count. WORST often starts at 100 or 200 from what I have seen.

From https://bugs.launchpad.net/ubuntu/+s...16/comments/40 :

Something to bear in mind as well:

smartmon does not always report SMART values as you might think. Different values are stored in different ways by different manufacturers.

Namely, if you do the smartctl check, wait for the click, and do it again immediately after, you may find that the amount has increased by more than one. In this case, it’s a pretty safe bet that the number you’re seeing isn’t accurate.

Also, it’s a pretty safe bet (though not guaranteed) that you can get the real value by dividing by the amount it increments by. So, if the value you see first is 477,296, and then it clicks once, and the value is 477,312 (difference of 16), it’s a pretty safe bet that the number you’re really dealing with is more along the lines of 29,831 to 29,832, in which case you have no worries.

If you think you might be suffering from this problem you might want to apply the ugly fix.

If you think your harddrive might start dying soon you should make backups of all your data and run the diagnostic tool of your harddrive manufacturer (which is probably included on the ultimate boot cd-rom).

The ugly fix :

You should only apply this fix if you feel your Load_Cycle_Count is increasing too fast. You should only apply this fix if you understand what you are doing so that you can reverse it. Apply this fix on your own risk. Also don't forget that having your harddisk head park protects your harddrive if you experience any bumps (which is especially nice if you are on the road and therefor probably working on battery).

Try the following :

$ sudo hdparm -B 254 /dev/sda

$ sudo hdparm -B 255 /dev/sda

One of these two will cause the drive will never be spun down and up again.

If hdparm solved your problem let's make these settings permanent. But first read why I'm recommending this :
http://ubuntuforums.org/showthread.p...55#post5038155

1) revert any previous fixes. remove all 99-hdd-spin-fix.sh files if any. comment the lines you added in /etc/hdparm.conf to fix this issue if any.
2) make a file named "99-hdd-ugly-fix.sh". The important thing is starting with "99".

$sudo gedit 99-hdd-ugly-fix.sh

3) make sure the file contains the following lines (fix it if you have PATA HDD):

#!/bin/bash
if on_ac_power; then
  # on AC so don't do any head parking
  hdparm -B 254 /dev/sda # you might need 255 or a different value
else
  # either on battery or power status could not be determined
  # so quickly park the head to protect the disk
  hdparm -B 128 /dev/sda
fi

4) copy this file to 4 locations:

$sudo install 99-hdd-ugly-fix.sh  /etc/acpi/resume.d/
$sudo install 99-hdd-ugly-fix.sh  /etc/acpi/start.d/
$sudo install 99-hdd-ugly-fix.sh  /etc/acpi/ac.d/
$sudo install 99-hdd-ugly-fix.sh /etc/acpi/battery.d/

By using install the file 99-hdd-ugly-fix.sh should have the x-bit set.

You probably shouldn't turn of head parking when on battery so you probably shouldn't use 254 when on battery. You should want your harddisk to park/unpark in order to safe power and protect your harddisk from bumps while on battery that's why we are using 128 while on battery. You might want to experiment with numbers between 128 (most head parks, best protection from bumps, lower power usage) and 254 (no protection from bumps,no head parks,best performance,increased heat). All values below 254 still can do much head parks (depending on the harddrive) so you should keep watching your Load_Cycle_Count.

Keep an eye on your harddisk temperature (for example using hddtemp) to make sure it doesn't exceed the harddisk's specifications. Keep an eye on your Load_Cycle_Count. If your Load_Cycle_Count is already close to it's specification (and behaves as a normal counter thus increments by 1) or your WORST is already at your THRESHOLD or very close to your THRESHOLD you should consider changing the "number for apm while on battery" (128) to 254 but you will lose any protection from bumps.

To get my disk temperature without disk activity (hddtemp causes disk activity) I'm using :
sudo smartctl -a /dev/sda | grep Temp

If you are worried about the temperature of your disk you might want to consider buying a laptop cooler. For my experiences with the Zalman ZM-NC2000 read :
http://ubuntuforums.org/showthread.php?t=818040
http://ubuntuforums.org/showpost.php...03&postcount=4

I didn't came up with this fix. Some contributions to this fix :
https://launchpad.net/ubuntu/+source...95/comments/14
https://launchpad.net/ubuntu/+source...95/comments/25
https://launchpad.net/ubuntu/+source...95/comments/99
http://www.linuxquestions.org/questi...97#post2939397
http://ubuntuforums.org/showpost.php...&postcount=487

Don't apply any unofficial ugly fixes unless you understand what you are doing and you understand how to revert. Only apply this fix if you are heavily affected. After applying this fix keep an eye on your Load_Cycle_Count and on your harddrive temperature and make sure it remains below the maximum temperature specification of your harddrive. Also don't forget that having your harddisk head park protects your harddrive if you experience any bumps (which is especially nice if you are on the road and therefor probably working on battery).Everything you do is on your own risk.

[ubuntu_demon]

Unofficial Ugly Load_Cycle_Count Fix for Hardy (and later Ubuntu versions)

Don't apply any unofficial ugly fixes unless you understand what you are doing and you understand how to revert. Only apply this fix if you are heavily affected. After applying this fix keep an eye on your Load_Cycle_Count and on your harddrive temperature and make sure it remains below the maximum temperature specification of your harddrive. Also don't forget that having your harddisk head park protects your harddrive if you experience any bumps (which is especially nice if you are on the road and therefor probably working on battery).Everything you do is on your own risk.

Please give me feedback so I can improve this post.

First read the first two posts of this thread which explain the problem and the fix for Gutsy :
http://ubuntuforums.org/showpost.php...46&postcount=1
http://ubuntuforums.org/showpost.php...46&postcount=2

acpi-support is being switched over to pm-utils. So the Gutsy fix might work for you in Hardy but it will probably not work any more in future releases (AFAIK). So the the Hardy fix is a work in progress to find a clean solution which will not depend on acpi-support but only on pm-utils in order to make it future proof. But the same principles apply so be sure to read the fix for Gutsy so you understand what you are doing.

Here's the fix for Hardy :
http://en.opensuse.org/Disk_Power_Management

The temperature of the disk seems a little bit higher for me in Hardy. Watch it very carefully!

I'm experimenting with these values but you might need different values :

DEVICES_DISK_PM_POWERSAVE_OFF="hdparm -q -B 254 -q -S 0"
DEVICES_DISK_PM_POWERSAVE_ON="hdparm -q -B 128 -q -S 0"

Also read about why I am recommending these values :
http://ubuntuforums.org/showpost.php...5&postcount=15

hddtemp bug :
http://ubuntuforums.org/showpost.php...2&postcount=27

This probably doesn't work for suspend/resume. We'll have to figure out what's the cleanest pm-utils based solution which works for suspend/resume. My laptop doesn't reliably suspend/resume so I can't test any suggested solutions myself.

The cleanest way I can currently think of is that this should be fixed is by making pm-utils call the scripts in /etc/pm/power.d after resuming/thawing. If that's done then Suse's workaround will work even after suspend/resume without any adaption.

I just reported this bug against pm-utils :
https://bugs.launchpad.net/ubuntu/+s...ls/+bug/235105

scripts in /etc/pm/power.d should be called after resuming/ thawing

Why ?
* the laptop might have switched from AC to battery or the other way around
* the harddrive 's apm settings might be reset to the default state
* this is needed for a clean workaround for the Load_Cycle_Count issue

To make sure your drive's apm settings are correct do the following after resume on battery :

sudo hdparm -B 128 /dev/sda

To make sure your drive's apm settings are correct do the following after resume on AC :

sudo hdparm -B 254 /dev/sda

To get your disk temperature without disk activity (hddtemp causes disk activity) use :
sudo smartctl -a /dev/sda | grep Temp

If you are worried about the temperature of your disk you might want to consider buying a laptop cooler. For my experiences with the Zalman ZM-NC2000 read :
http://ubuntuforums.org/showthread.php?t=818040
http://ubuntuforums.org/showpost.php...03&postcount=4

Please give me feedback so I can improve this post.

Don't apply any unofficial ugly fixes unless you understand what you are doing and you understand how to revert. Only apply this fix if you are heavily affected. After applying this fix keep an eye on your Load_Cycle_Count and on your harddrive temperature and make sure it remains below the maximum temperature specification of your harddrive. Also don't forget that having your harddisk head park protects your harddrive if you experience any bumps (which is especially nice if you are on the road and therefor probably working on battery).Everything you do is on your own risk.

[hotweiss]

I have a problem, the load cycle count issue comes back after I resume my computer from suspend. I'm using Ubuntu 8.04.

[sam_delta]

I have a problem, the load cycle count issue comes back after I resume my computer from suspend. I'm using Ubuntu 8.04.

you copied the script to resume.d?

 sudo install 99-hdd-ugly-fix.sh  /etc/acpi/resume.d/

sam

[Arthur Archnix]

I have a similar problem with the SUSE fix using Hardy as Hotweiss, but only if I resume while on ac. If I resume from suspend on battery the SUSE fix applies the hdparm setting of B at 200 correctly. This is regardless of whether I suspended while on battery or on AC. If I resume while on AC it reverts to 128. From boot on either battery or ac the correct settings are applied (e.g., 200 on Battery, disabled on AC). This is a pretty clean install of Hardy with the following changes:

I've uninstalled cron, anacron, sysklog, klogged, trackered, and mapped acpid logging to /dev/null. I've upped ext3 committ time to 30 seconds and set data mode to write back while using noatime on all partitions. While having nothing open or running but my gnome desktop load/cycle counts increase by about once per 3 or 4 seconds.

Unfortunately in my case, this is almost certainly a case of bad HD firmware. I appreciate all the hard word demon put into his Gutsy fix. Aside from the minor annoyance of having to manually unplug the power cord and plug it back in after suspend, the suse fix works fine for me under Hardy. Perhaps one day soon we'll have a reliable script that will trick Ubuntu into thinking that the plug has been removed and inserted after a suspend. Until then, thanks again Ubuntu Demon.

Hotweiss, have you checked before suspend, after suspend, while on a/c and battery, and the various combinations? And after resume fom suspend if you unplug and plug back in does it adopt correct settings?

I'm using the following command to query the setting:

sudo hdparm -I /dev/sda | grep level

If you use the command on the SUSE link to check there is no way to tell if a setting of 128 or 200 is applied, because it only shows on versus off for power management. The command above will give you the exact power saving number, or disabled.

EDIT: re sam's comment above, that only applies to gutsy. Those scripts aren't used nor installed to those locations on Hardy. At least, that's my understanding and someone will correct me if I'm mistaken.

[garoth2]

I'm not certain whether Hardy is actually using pm-utils. Using the instructions on the opensuse site - placing that script in /etc/pm/config.d did not execute/change my PM settings.

I tried putting the scripts in /etc/acpi/* and it seems to have worked

[Rayaz]

I'm not certain whether Hardy is actually using pm-utils. Using the instructions on the opensuse site - placing that script in /etc/pm/config.d did not execute/change my PM settings.

I tried putting the scripts in /etc/acpi/* and it seems to have worked

Can confirm putting scripts in /etc/acpi/* works for Hardy.
Though am concerned about the HDD temperature which has gone from 29 C to 46 C in 30 minutes just browsing the net.

[garoth2]

Are you sure about that first reading?

My HDD temp seems to not have changed much. About 40-45 deg C

[hotweiss]

I have a similar problem with the SUSE fix using Hardy as Hotweiss, but only if I resume while on ac. If I resume from suspend on battery the SUSE fix applies the hdparm setting of B at 200 correctly. This is regardless of whether I suspended while on battery or on AC. If I resume while on AC it reverts to 128. From boot on either battery or ac the correct settings are applied (e.g., 200 on Battery, disabled on AC). This is a pretty clean install of Hardy with the following changes:

I've uninstalled cron, anacron, sysklog, klogged, trackered, and mapped acpid logging to /dev/null. I've upped ext3 committ time to 30 seconds and set data mode to write back while using noatime on all partitions. While having nothing open or running but my gnome desktop load/cycle counts increase by about once per 3 or 4 seconds.

Unfortunately in my case, this is almost certainly a case of bad HD firmware. I appreciate all the hard word demon put into his Gutsy fix. Aside from the minor annoyance of having to manually unplug the power cord and plug it back in after suspend, the suse fix works fine for me under Hardy. Perhaps one day soon we'll have a reliable script that will trick Ubuntu into thinking that the plug has been removed and inserted after a suspend. Until then, thanks again Ubuntu Demon.

Hotweiss, have you checked before suspend, after suspend, while on a/c and battery, and the various combinations? And after resume fom suspend if you unplug and plug back in does it adopt correct settings?

I'm using the following command to query the setting:

sudo hdparm -I /dev/sda | grep level

If you use the command on the SUSE link to check there is no way to tell if a setting of 128 or 200 is applied, because it only shows on versus off for power management. The command above will give you the exact power saving number, or disabled.

EDIT: re sam's comment above, that only applies to gutsy. Those scripts aren't used nor installed to those locations on Hardy. At least, that's my understanding and someone will correct me if I'm mistaken.

I'm still having the same problem even after applying the ugly fix. I ran sudo hdparm -I /dev/sda | grep level after suspend and resume, and got this:

Advanced power management level: 128

Since I'm on AC power shouldn't it be 254?