High frequency of load/unload cycles on some hard disks may shorten lifetime

Bug #59695 reported by Gilles Schintgen
842
This bug affects 80 people
Affects Status Importance Assigned to Milestone
acpi-support
Invalid
Undecided
Unassigned
Suse
Fix Released
Unknown
acpi-support (Baltix)
Fix Released
Undecided
Unassigned
acpi-support (Debian)
Fix Released
Unknown
acpi-support (Ubuntu)
Fix Released
Critical
Steve Langasek
Declined for Dapper by Steve Langasek
Declined for Edgy by Timo Aaltonen
Declined for Feisty by Steve Langasek
Declined for Gutsy by Steve Langasek
Nominated for Karmic by Metzelmaennchen
Nominated for Lucid by Metzelmaennchen
Nominated for Maverick by Kikko
Hardy
Fix Released
Critical
Steve Langasek
Intrepid
Fix Released
Critical
Steve Langasek
Jaunty
Fix Released
Critical
Steve Langasek
laptop-mode-tools (Mandriva)
Unknown
Critical
linux-meta (Ubuntu)
Invalid
Undecided
Unassigned
Declined for Dapper by Steve Langasek
Declined for Edgy by Timo Aaltonen
Declined for Feisty by Steve Langasek
Declined for Gutsy by Steve Langasek
Nominated for Karmic by Metzelmaennchen
Nominated for Lucid by Metzelmaennchen
Nominated for Maverick by Kikko
Hardy
Invalid
Undecided
Unassigned
Intrepid
Invalid
Undecided
Unassigned
Jaunty
Invalid
Undecided
Unassigned
pm-utils (Fedora)
Invalid
Medium
pm-utils (Ubuntu)
Fix Released
Undecided
Unassigned
Declined for Dapper by Steve Langasek
Declined for Edgy by Timo Aaltonen
Declined for Feisty by Steve Langasek
Declined for Gutsy by Steve Langasek
Nominated for Karmic by Metzelmaennchen
Nominated for Lucid by Metzelmaennchen
Nominated for Maverick by Kikko
Hardy
Fix Released
Critical
Steve Langasek
Intrepid
Fix Released
Critical
Steve Langasek
Jaunty
Fix Released
Undecided
Unassigned

Bug Description

The kernel wiki gathers info about drives with too aggressive power saving defaults. A script called "storage-fixup" is also available.
https://ata.wiki.kernel.org/index.php/Known_issues#Drives_which_perform_frequent_head_unloads_under_Linux

This is not a support forum. Please do not use it as such (even though it has been used as such already).

You can scan through the bug for links to the Ubuntu forums where many, many different questions have been asked, answered, and re-answered. The temporary workaround is just below.

See https://wiki.ubuntu.com/PowerManagement for an overview about what is involved and for a remedy.

SRU justification: current behavior may lead to premature disk failure in laptops due to excessive unnecessary drive parking. Fix will disable disk cycling by default when on AC power, by correcting an error in the hdparm logic of acpi-support.

For jaunty, this issue is addressed in acpi-support 0.115.

TEST CASE:

1. With acpi-support 0.109 (hardy) or 0.114 (intrepid) installed and laptop-mode *not* enabled in either /etc/default/laptop-mode or /etc/default/acpi-support, monitor the load cycle count of your hard drive by running 'sudo smartctl -a /dev/sda|grep Load_Cycle_Count' over an interval of several minutes, and observe that it is incrementing. (If it does not increment, your hard drive's manufacturer defaults are sane and you are not affected by this problem.)
2. install acpi-support from hardy-proposed or intrepid-proposed
3. while connected to AC power, monitor 'sudo smartctl -a /dev/sda|grep Load_Cycle_Count' again to confirm that the number is no longer incrementing
4. (assuming that the system is a laptop:) disconnect the system from AC power, and confirm that the number is incrementing again
5. enable laptop mode by setting ENABLE_LAPTOP_MODE=true in /etc/default/laptop-mode and running 'sudo /etc/init.d/laptop-mode restart'
6. reconnect the system to AC power and confirm that the Load_Cycle_Count stops incrementing.
7. suspend and resume the system and confirm that the Load_Cycle_Count is still not incrementing.

REGRESSION POTENTIAL:

As this patch causes "hdparm -B 128" and "hdparm -B 254" to be invoked automatically on systems where it was not being run before, there is some risk that this change will have a measurable impact on the disk throughput, power consumption, and temperature of some hard drives. Nevertheless, it is believed that these APM power settings are the sensible default settings for the vast majority of hard drives and that the current behavior poses a significant risk to the longevity of hard drives used in a wide range of laptop models, so this update should only be blocked if it results in confirmed hardware damage that can be expected to apply to a similar range of configurations.

Following is a summary of the issue:
It is confirmed that some systems are seeing an unusually high number of load/unload cycles on their hard disks, as evidenced by smartctl.

It was originally surmised that this was related to laptop-mode being enabled, but this especially affects systems where laptop-mode is disabled. In fact, aggressive APM is not a bad idea while a system is not on AC, as that system is much more likely to encounter a physical impact.

This is due to disk APM settings that let the heads park or disk spin down after an idle period that is shorter than the regular disk access patterns of the OS.

Then, the heads are only parked for a very short period of time and almost imediately loaded again. Making impact protection much ineffective and wearing out the drive.

It can happen when the disk asumes aggressive APM settings (like many laptop disks) and the OS does not take care to set the APM settings accordingly to its current disk access pattern.

This problem has been confirmed in Ubuntu as well as in other distributions and on MacOS X and Windows.

Symptoms of this bug are:
* Frequent HD clicks -- more than one per 3 minutes while idle, louder than the typical access sounds. Often more than twice per minute. On some disks, the click is very quiet
* Rapidly Increasing Load_Cycle_Count as displayed in the final number in "sudo smartctl -a /dev/hda | grep Load_Cycle_Count" (where /dev/hda is replaced with your own hard disk device)

The problem is only present due to the existence of *all four* of the following factors:
* Hardware is set (default or otherwise) to aggressive power management, causing heads to park. (default behaviour of many drives and often the only user available type of power management)
* Disk is touched often, causing heads to unpark. (default behaviour of many distributions)
* Drives are spec'd to a limited number of these cycles. (600,000 is the most common, although some may be spec'd higher or lower).
* The OS not setting disk APM variables according to current disk access pattern.

Reasonable Limits / Criteria for a fix:
* There should be fewer than ~15 load cycles per hour, except during heavy usage while on battery.
* This provides a life expectancy of over four years, which is reasonable for a hard disk.

Temporary Workaround:
* Follow the above link.

Some hardware with this issue:
WD1200VE -- http://www.wdc.com/en/library/portable/2879-001121.pdf -- This aggressive parking is a feature of this disk, but that feature relies on behaviour that allows for significant amounts of (truly) idle time without the disk being touched. Notice the "Load/unload cycles" of 600,000.

Example Load_Cycle_Counts:
* Thinkpad Z60m/Hitachi HTS541080G9SA00 with well over 7000 load cycles in only 100 hours. That's >70 per hour.
* Gateway MT6451/Western Digital WD1200VE with 164762 load cycles in 3747 hours (156 days) of uptime. That's ~43 per hour -- except that the system was patched during the initial third of its life, which puts it at ~63/hour since Gutsy was installed (and wasn't patched, as I had done with feisty).
* Dell Inspiron 8600/Hitachi HTS721010G9AT00 with 200 to 280 load cycles per hour

Please see for yourself how often your drive is load cycling:
smartctl -d ata -a /dev/sda
(This command is for an SATA drive; you'll need to install the smartmontools package first.)

You can get the average per hour by the following division:
Load_Cycle_Count / Power_On_Hours

Old workaround for 7.10 (not working in 8.04): https://bugs.launchpad.net/ubuntu/+source/acpi-support/+bug/59695/comments/14
A more extensive description of the workaround: http://ubuntuforums.org/showthread.php?t=591503

You may need to use '254', or a bit lower, as opposed to '255'. If HD temperature gets high, you may want to set it all the way "down" to 200 or so. ~1 click every 2.5-3 minutes is fine.
Note: Some disks are unresponsive to having their APM changed by hdparm, and therefore the workaround doesn't work. It would be a good idea, in such cases, to disable APM in the BIOS if possible.

See also http://paul.luon.net/journal/hacking/BrokenHDDs.html for a rather dramatic account of the effects the current default values may have.

Revision history for this message
Loic Pefferkorn (loic) wrote :

I can confirm this behavior with my T43

Changed in acpi-support:
assignee: nobody → ubuntu-laptop
importance: Untriaged → Wishlist
status: Unconfirmed → Needs Info
Revision history for this message
Gilles Schintgen (shigi) wrote : Re: [Bug 59695] Re: default value in power.sh potentially kills laptop disks

> I can confirm this behavior with my T43
Thanks for confirming. So now we'll have to determine sane default values.
I did some very unscientific tests using the command

smartctl -d ata -a /dev/sda | grep 193; hdparm -B 180 /dev/sda; sleep 600; \
smartctl -d ata -a /dev/sda | grep 193; hdparm -B 255 /dev/sda

and continuing to work normally. After 10 minutes I checked the output.

Here are some values:
-B 128 -> 23 cycles in 10 minutes
-B 160 -> 29 in 10'
-B 180 -> 0 in 10'
-B 196 -> 0 in 10'
-B 200 -> 0 in 10'

So even -B 160 leads to 3 cycles per minute (180 per hour), leading to a
lifespan of 600,000/180/24=139 days (of continuous battery powered use).
Note that only a few years ago 300,000 load/unload cycles was a common value.

What is remarkable is the sharp drop between 180 and 196. Could somebody else
report some values for his system?

Does anyone know how the -B parameter is interpreted or is that left up to the
device?

Revision history for this message
Gilles Schintgen (shigi) wrote : Re: [Bug 59695] default value in power.sh potentially kills laptop disks

> When switching to battery power, /etc/acpi/power.sh issues the command
> hdparm -B 1 to all block devices.
But only if laptop mode is enabled.
However in my case laptop mode is still _disabled_
in /etc/default/acpi-support. So, if I'm understanding the power.sh script
correctly it's _not_ this script which causes these frequent load cycles.
Hence my original report was wrong. Sorry about that.

Some more investigation led me to the following page:
http://www.thinkwiki.org/wiki/Problem_with_hard_drive_clicking
It seems that Hitachi is using some quite aggressive power management.

I'm not sure what to do about this report. If it really turns out to be a
hardware problem it should probably be closed.

Revision history for this message
Peter Funk (pf-artcom-gmbh) wrote : Re: default value in power.sh potentially kills laptop disks

Running Ubuntu 6.10 on brand new HP compaq nw9440 with a Seagate ST910021AS
since February 27th: Load Cycle Count 134608 in 2 and half month ! :-(
I also noticed the hard drive clicking noise quite frequently and using Google
I stumbled over your bug report here. I'm using XFS as a filesystem, if
this mattern anyhow in this issue.
Update: after 10 minutes with ``hdparm -B 180 /dev/sda`` the load cycle
count has increased to 134616. I will now try the command
``smartctl -o on /dev/sda`` as suggested on the thinkwiki page mentioned
in the thread here.

Revision history for this message
Gilles Schintgen (shigi) wrote :

Please increase the importance of this issue. I'm really concerned about my disk's health.

I was noticing some clicking but didn't think much about it since I "fixed" this issue a long time ago. Only now it occurred to me that maybe some update overwrote my changes.

Unfortunately this seems to be the case. Here's the current stats from my disk (the thinkpad is from august 2006!):
192 Power-Off_Retract_Count 0x0032 100 100 000 Old_age Always - 7143426

Over 7 MILLION retracts! I'm wondering how long it will hold. I just find it curious that "value" is still at "100" whereas the threshold (for failure) is "000".

Revision history for this message
Gilles Schintgen (shigi) wrote :

Oh well...

Forget about my last comment. I was looking at "192 Power-Off_Retract_Count" instead of "193 Load_Cycle_Count" and freaked out. I guess I need some sleep.

Anyway, what is Power-Off_Retract_Count and how can it reach 7,000,000?

Revision history for this message
TDB (michael-baranov) wrote :

Please increase the importance of this issue!
``hdparm -B 255 /dev/sda`` works like a charm!
changing 1=>255 in /etc/acpi/power.sh does not seem to work for me.

Toshiba P205, FUJITSU MHW2120BH

Revision history for this message
TDB (michael-baranov) wrote :

Oh... seems like when going out of hibernate/suspend the effect of ``hdparm -B 255 /dev/sda`` disappears. Need to re-issue it again. Can somebody help me with executing this on 1) boot 2) return from hibernate 3) return from suspend, PLZ?

Revision history for this message
TDB (michael-baranov) wrote :

I wonder if /etc/hdparm.conf can help...

BTW: https://bugs.launchpad.net/ubuntu/+bug/104535

Revision history for this message
Gilles Schintgen (shigi) wrote :

It seems that I completely forgot to publish my fix/workaroud. As far as I remember I did two things:

1) I added the following lines to my hdparm.conf:
/dev/sda {
  apm = 255
}

2) I created a file /etc/acpi/resume.d/99-stop-hitachi-madness.sh
with the following contents:
#!/bin/sh
hdparm -B 255 /dev/sda

I hope this helps.

Revision history for this message
TDB (michael-baranov) wrote :

Gilles, thanks! The first workaround that actually works.

IMO, modifying hdparm.conf has no effect because the "last word" is said by /etc/acpi/resume.d/99foo.sh
I've also added the same script to /etc/acpi/start.d/

Oh... now with kernel 2.6.22 (emergency unloads on shutdown fixed) and this fix my HDD can rest at ease...

Revision history for this message
William (williamc-sp) wrote : THIS IS REALLY A PROBLEM ... Re: default value in power.sh potentially kills laptop disks

Confirmed also with my Hitachi HTS541210H9SA00 (which has used up 10% of its life in less than a month :( ). Needless to say I would suggest this bug have very high priority. I am surprised that it has persisted as long as it has --- Ubuntu is meant to be harmless, but, it isn't at the moment.

Changed in acpi-support:
status: Incomplete → Confirmed
Revision history for this message
unknown (stealthbox) wrote : Re: default value in power.sh potentially kills laptop disks

I can confirm this bug on my inspiron 1501, the hd light goes on way too much compared to xp. Its a shame this isnt considered important. I guess i cant use ubuntu on my laptop

Revision history for this message
TDB (michael-baranov) wrote :

Here is how I permanently fixed it:

1) make a file named "99-hdd-spin-fix.sh". The important thing is starting with "99".
2) make sure the file contains the following 2 lines (fix it if you have PATA HDD):
#!/bin/sh
hdparm -B 255 /dev/sda
3) copy this file to 3 locations:
/etc/acpi/suspend.d/
/etc/acpi/resume.d/
/etc/acpi/start.d/

Voila! After that the HDD never spins down on power (looks like it actually spins down on battery at modest rate).
Sorry if the instruction is too detailed, no offense.

Revision history for this message
TDB (michael-baranov) wrote :

Ah... the same workaround posted by someone else before me.... sorry.

Revision history for this message
ramas (slocascio) wrote :

The command hdparm -b 255 turn off completely APM.
This could last HD life by saving load cycles.
On the other hand, the HD temperature could get very HOT (51°c on my Inspiron), also decreasing drive life.

I wonder if there is another better solution to this, for example using SMART functions with smartctl.
BTW fot Itachi drives I found this page that could help: http://www.dellcommunity.com/supportforums/board/message?board.id=insp_harddrive&thread.id=38562&view=by_date_ascending&page=1

Revision history for this message
Bart Samwel (bart-samwel) wrote : Re: [Bug 59695] Re: default value in power.sh potentially kills laptop disks

ramas wrote:
> The command hdparm -b 255 turn off completely APM.
> This could last HD life by saving load cycles.
> On the other hand, the HD temperature could get very HOT (51°c on my Inspiron), also decreasing drive life.
>
> I wonder if there is another better solution to this, for example using SMART functions with smartctl.
> BTW fot Itachi drives I found this page that could help: http://www.dellcommunity.com/supportforums/board/message?board.id=insp_harddrive&thread.id=38562&view=by_date_ascending&page=1

AFAICT this page simply describes a tool for Windows that does exactly
what hdparm does, except that it sets the default for the drive. Nothing
new there.

Cheers,
Bart

Revision history for this message
TDB (michael-baranov) wrote : Re: default value in power.sh potentially kills laptop disks

@ramas
AFAIK modern drives are able to handle high temps just fine. Up to 75 C is OK. More over, 2,5" HDDs produce max 2 wats of heat on idle spin, so unless you keep the lead of your laptop closed and the HDD spinning overnight, you won't have any heat problems.

Revision history for this message
Don Mullis (don.mullis) wrote :

An alternative to the "99-hdd-spin-fix.sh" fix is to install and enable the package laptop-mode-tools,
then customize /etc/laptop-mode/laptop-mode.conf, setting

CONTROL_HD_POWERMGMT=1

Revision history for this message
Mike C. (launchpad-christiansons) wrote :

I am also experiencing this issue on my Dell Inspiron 6400.

According to smartctl, my load cycle count is 73,603. Now, I’ve had my 6400 for five months, so that’s ~484 cycles per day. At this rate my hard drive (HTS721010G9SA00) will “last” ~3.5 years.

Revision history for this message
Martin Polden (martin-polden) wrote :

I have the same problem on a M1330. I've only been using it since Friday the 19th and my load cycle count is already at 851. I managed to "slow it down" by doing sudo hdparm -B 254 /dev/sda.

Revision history for this message
Jens Berke (jensberke) wrote :

Behaviour confirmend on an IBM Thinkpad R52 with harddisk Hitachi HTS541060G9AT00. Default value for APM is 128 after a clean install of Gutsy Gibbon. A value of 192 or bigger, set with "hdparm -B", seems to be the range of values with no load cycles.

The load cycles are *not* limited to battery power mode on my system. I also had them when not in battery power mode.

Revision history for this message
brokencrystal.com (admin-brokencrystal) wrote :

Since this can significantly shorten the life of your hard drive, shouldn't this bug be listed a little higher in importance than just a wishlist?

Revision history for this message
Christian Wolf (christianwolf) wrote :

All 3 of my laptops are also affected. The suggested fix with "hdparm -B 180" however does not work for all harddrives. On my HITACHI_DK239A-65B (old Notebook drive in my Thinkpad 600E) for example, it does exactly the opposite when the laptop was set into laptop mode - it then starts frequent harddrive access every 10 sec which are otherwise turned off when in laptop mode. I have to turn OFF S.M.A.R.T with smartctl -s off /dev/hda and then to start laptop-mode AND in order to stop all unneccessary HD access.

By the way, this is my reload_cycle number for this 9 yr old harddrive, used as my webserver:
225 Load_Cycle_Count 0x0012 100 100 050 Old_age Always - 1627390049

Lovely :-) What is this numer - billions?

Seriously: I think that marking this severe issue as "Wishlist" is inapproprate. Also, not issuing a public warning reminds me to the behaviour of a software company based in Redmond, USA and is not nice to to all Ubuntu supporters who trust Canonical and the developers. Ubuntu is not perfect, but we have nothing to hide, even if a bug like this could cause bad press.

From the Ubuntu Code of Conduct:
Be considerate. Your work will be used by other people, and you in turn will depend on the work of others. Any decision you take will affect users and colleagues, and we expect you to take those consequences into account when making decisions.

Ty for your consideration.

Revision history for this message
Martin Polden (martin-polden) wrote :

As a temporary fix I edited /etc/hdparm.conf and added:

/dev/sda {
  apm = 255
  spindown_time = 0
}

Afterwards I installed the hdparm init script by doing 'sudo update-rc.d hdparm defaults' to make the changes consistent over reboots.

This is the same as running the following commands:
hdparm -B255 /dev/sda
hdparm -S0 /dev/sda

This will turn off Advanced Power Management on the drive and it will disable the standby (spindown) timeout, so the drive will never be spun down and up again.

Revision history for this message
SendDerek (sendderek) wrote :

Is there any way to brief a beginner on how to read the output of "smartctl -d ata -a /dev/sda"? I'm having a hard time finding the line where it states "xx cycles in xx minutes". Here is what I can see from this command (some info has been left out):

Model Family: Hitachi Travelstar 5K100 series
Device Model: HTS541010G9SA00
Firmware Version: MBZOC65D
User Capacity: 100,030,242,816 bytes
Device is: In smartctl database [for details use: -P show]
ATA Version is: 7
ATA Standard is: ATA/ATAPI-7 T13 1532D revision 1
Local Time is: Wed Oct 24 07:06:02 2007 MDT
SMART support is: Available - device has SMART capability.
SMART support is: Enabled

Vendor Specific SMART Attributes with Thresholds:
193 Load_Cycle_Count 0x0012 066 066 000 Old_age Always - 349519

Revision history for this message
Joey Stanford (joey) wrote :

I have been able to confirm this on my System76 Darter. It appears to also have been the problem I've been seeing since feisty where the HD seems to always be in use. By deactivating APM (e.g. hdparm -B 255 /dev/sda ), my always in use issue has been resolved. My current Load Cycle is 333001 on a machine I bought in March. Also to note, that the load cycle increases also on AC Power, although not near as frequently as with laptop mode.

Revision history for this message
Blue (vali-dragnuta) wrote :

I confirm this and more : same behaviour on a _desktop_ computer. This because on that desktop on_ac_power returns nonzero and the system thinks it's running on batteries.
The actual hdparm setting is here :
/etc/apm/event.d/20hdparm
This creates TWO new bugs :
1. first one is that this script runs AFTER /etc/init.d/hdparm so if we set -S0 in /etc/hdparm.conf to disable this behaviour , the setting will have no effect as it will be overset by 20hdparm
2. second bug is that in /etc/apm/event.d/20hdparm line 64 the script does not treat the case where on_ac_power returns 255 (could not determine state). In this case, the power conserve mode should NOT be activated.

Anyway, as a temporary workaround you can edit /etc/apm/event.d/20hdparm and set on line 32 APMD_SPINDOWN to a saner value. Also, it would be nice to move this parameter in /etc/default so that it is cleanly configurable.

Revision history for this message
Blue (vali-dragnuta) wrote :

I think this deserves a greater importance than "wishlist".
A value of 18 for hdparm -S translates to 90 seconds, and this is insane, because even let to idle the system will try write to the disks every 2..4 minutes.
That means that the disk idles for 90 seconds and spins down and after another 90 seconds the system wants to write on it and it spins it up again. So, even with an idle system
the hard disk will be spinned up 90 seconds and spinned down the next 90. Not only this is dangerous, but it's useless from a power management point of view.

Revision history for this message
CheolHan Yoon (mait) wrote :

It's not 'wishlist', just 'critical issue'.

I've had same problem, and now solved with martin's tweak.

Quote,

As a temporary fix I edited /etc/hdparm.conf and added:

/dev/sda {
  apm = 255
  spindown_time = 0
}

Afterwards I installed the hdparm init script by doing 'sudo update-rc.d hdparm defaults' to make the changes consistent over reboots.

Thnks, martin.

Revision history for this message
Blue (vali-dragnuta) wrote :

Please note that that editing hdparm.conf alone does NOT solve the problem, see comment 58 for details.

Revision history for this message
Chris Moore (dooglus) wrote :

Which comment do you mean, Blue? Yours is comment 31. Do you have abilities to predict the future? If so, will this laptop of mine be killed for a 2nd time by this bug before its 12 month warranty expires?

Revision history for this message
Martin Polden (martin-polden) wrote :

Editing hdparm.conf alone is not enough and as I wrote in my previous comment, you have to run 'sudo update-rc.d hdparm defaults' too so that the hdparm init script is added to the approperiate runlevels (2, 3, 4 and 5). Runlevel 2 is the last runlevel and scripts in this runlevel are executed last, you can verify this by running the 'runlevel' command after you log in.

Revision history for this message
Christian Wolf (christianwolf) wrote :

WARNING:

Fiddling around with hdparm might stop the unload/load cycles but can also dramatically increases HD Temp - at least here on my Compaq Evo600N:

192 Power-Off_Retract_Count 0x0032 100 100 000 Old_age Always - 12
193 Load_Cycle_Count 0x0032 094 094 000 Old_age Always - 67387
194 Temperature_Celsius 0x0022 100 100 000 Old_age Always - 50 (Lifetime Min/Max 16/50)

-->we have winter, the laptop is being used as a web server, low load, in a very cold room (14 degress Celsius!!) The fan is going on constantly to cool down the HD.
I took the -B 200 value, which works fine for my HP NX6325 - but NOT for this machine. I have to check if this is connected with laptop-mode - although I am on cable, it seems to be activated during boot up.

So careful with modifying APM values with hdparm.....

I think this bug does not get more importance until Mark Shuttleworth notebook dies from it :-((((((

Revision history for this message
Blue (vali-dragnuta) wrote : Re: [Bug 59695] Re: default value in power.sh potentially kills laptop disks
Revision history for this message
Blue (vali-dragnuta) wrote : Re: default value in power.sh potentially kills laptop disks

I would rather suggest to modify /etc/apm/event.d/20hdparm and at line 32 instead of
APMD_SPINDOWN=18

put
APMD_SPINDOWN=180 # 15 minutes instead of 90 seconds.

You can also set /etc/hdparm.conf, but as long as the apmd service is activated the setting in /etc/hdparm.conf will be useless, so if you modify hdparm.conf please
don't forget to make sure that hdparm is executed at boot (use rcconf,update-rc.d or services admin for that) AND make sure that you either modify the APMD_SPINDOWN or disable the apmd service using the previously mentioned rc tools.
I had a longer discussion with Martin by email and he had apmd disabled - that's why his hdparm.conf setting was not overset.
Anyway, 90 seconds is insane as default value.
And I also want to reiterate that the same apm script incorrectly assumes a on-battery configuration when it can't actually figure out if we are running on ac power or on battery (the special case 255 returned by on_ac_power ).

Revision history for this message
Joey Stanford (joey) wrote :

Keep in mind that you can change the acpi spindown time in /etc/defaults/acpi-support. restarting the acpi-support service should enable the new times. I'm unfortunately not a power management expert so your mileage may vary.

Revision history for this message
Kamil Páral (kamil.paral) wrote :

I have Dell Latitude C640 with Western Digital 40GB. The harddisk is 3 days old (brand new) and I have 900 load cycle count. My harddisk "clicks" (increases load cycle count) roughly twice a minute (regardless battery or AC mode), but (this is important) only when there is absolutely no other harddisk activity. If I use some app which few times a minute reads or writes a file, there is no load cycle count increase.

I have also tried Windows XP - there is no cycle count increase, no hdd clicking. In BIOS, hdd clicks once (the sound is distinguishable from normal activity) - after that, it's silent. In Ubuntu 7.10, twice a minute.

For those who have IBM/Hitachi, you can try download Hitachi Feature Tool
http://www.hitachigst.com/hdd/support/download.htm
and disable/tweak APM manually right from that livecd. Maybe after that you will not have to hack scripts (maybe it can "force" the APM setting), but I am not sure of that.

Revision history for this message
Brian Ealdwine (eode) wrote : Re: [Bug 59695] Re: default value in power.sh potentially kills laptop disks

I wonder if it's going into sleep, and then trying to write to the log
that it has gone to sleep.. That would be a big 'duh'.

On Wed, 2007-10-24 at 22:43 +0000, Kamil Páral wrote:
> I have Dell Latitude C640 with Western Digital 40GB. The harddisk is 3
> days old (brand new) and I have 900 load cycle count. My harddisk
> "clicks" (increases load cycle count) roughly twice a minute (regardless
> battery or AC mode), but (this is important) only when there is
> absolutely no other harddisk activity. If I use some app which few times
> a minute reads or writes a file, there is no load cycle count increase.
>
> I have also tried Windows XP - there is no cycle count increase, no hdd
> clicking. In BIOS, hdd clicks once (the sound is distinguishable from
> normal activity) - after that, it's silent. In Ubuntu 7.10, twice a
> minute.
>
> For those who have IBM/Hitachi, you can try download Hitachi Feature Tool
> http://www.hitachigst.com/hdd/support/download.htm
> and disable/tweak APM manually right from that livecd. Maybe after that you will not have to hack scripts (maybe it can "force" the APM setting), but I am not sure of that.
>

Revision history for this message
Martin Wilson (martinmwilson) wrote : Re: default value in power.sh potentially kills laptop disks

I just want to chime in with all the others that are frustrated this is listed as "wishlist". I know a quick triager may have just skimmed and not noticed the importance. But, now that this is getting more attention from people affected, it's clear this is a critical priority issue.

Please reevaluate the importance of this issue.

Revision history for this message
Daniel Hahler (blueyed) wrote :

Blue, thanks for your investigations. This looks like two bugs (too low default value and wrong handling of return code 255) in /etc/apm/event.d/20hdparm then, correct?

re init script: Ubuntu seems to use udev only, instead of the init script. But it appears to only hook into udev for hd[a-z] devices (I've just filed bug 156893 about this).

So, this part seems to be bugs in the "hdparm" package.

In acpi-support's /etc/acpi/power.sh:
"hdparm -B 1" sets "most aggressive power management".
power.sh additionally calls "hdparm -S $SPINDOWN_TIME" in the laptop_mode_enable function, where $SPINDOWN_TIME defaults to 12 (at least that's what I have here) - so I guess the latter "hdparm -S 12" is the real culprit here (it's even lower than APMD_SPINDOWN=18). This would led to spinning down the drive after 60 seconds.

I'm not sure, if actually spinning down (-S) or APM features (-B) are the problem here. Probably both?
Are the settings in /etc/apm/event.d/20hdparm considered/relevant at all?

Please add information about the distribution you are using and if you have /dev/hd[a-z] or /dev/sd[a-z] devices.

Probably in /etc/apm/event.d/20hdparm the SPINDOWN_TIME value from /etc/default/acpi-support should get used by default?!

Revision history for this message
Daniel Hahler (blueyed) wrote :

I've created a patch, addressing the hdparm issues:
- APMD_SPINDOWN=60 for spindown after 5 minutes instead of 1.5 minutes
- handle "dunno" return value from on_ac_power in choose_power and do not assume laptop mode in this case

I think 5 minutes is a reasonable compromise, but I'm no laptop user at all.

Please note, that this only addresses the "hdparm -S" setting in the apm hook file. This may be totally wrong/incomplete!

Revision history for this message
Daniel Hahler (blueyed) wrote :

I've created a patch, addressing the hdparm issues:
- APMD_SPINDOWN=60 for spindown after 5 minutes instead of 1.5 minutes
- handle "dunno" return value from on_ac_power in choose_power and do not assume laptop mode in this case

I think 5 minutes is a reasonable compromise, but I'm no laptop user at all.

Please note, that this only addresses the "hdparm -S" setting in the apm hook file. This may be totally wrong/incomplete!

Revision history for this message
Apreche (apreche) wrote :

I can almost 100% confirm that this problem killed the 1.8" 40 gig Toshiba drive in my Fujitsu P7230. However, I am not upset because I have replaced it with a solid state drive that works quite well.

Revision history for this message
Eric Grigg (ericgrigg-deactivatedaccount) wrote :

Will this patch end up in Gusty or go into Hardy?

Revision history for this message
Matthew Garrett (mjg59) wrote :

By default, we do nothing to set any disk power values. It's arguable that the configuration file should make it clearer to the user that enabling aggressive power management will result in a shorter hard drive life, but it's also an inevitable consequence of enabling that aggressive power management. The stock install is entirely safe in this respect.

Revision history for this message
Matthew Garrett (mjg59) wrote :

Inserting scripts in /etc/apm is unlikely to help anything - we don't execute them on any laptop made since 2001.

Revision history for this message
Tim Hull (thully) wrote : Re: [Bug 59695] Re: default value in power.sh potentially kills laptop disks

In that case, something should be done, as aggressive power management is
enabled by default - and as the reports demonstrate, this is causing a
significantly shorter disk life than on other OSes.

On 10/24/07, Matthew Garrett <email address hidden> wrote:
>
> By default, we do nothing to set any disk power values. It's arguable
> that the configuration file should make it clearer to the user that
> enabling aggressive power management will result in a shorter hard drive
> life, but it's also an inevitable consequence of enabling that
> aggressive power management. The stock install is entirely safe in this
> respect.
>
> --
> default value in power.sh potentially kills laptop disks
> https://bugs.launchpad.net/bugs/59695
> You received this bug notification because you are a direct subscriber
> of a duplicate bug.
>

Revision history for this message
Matthew Garrett (mjg59) wrote : Re: default value in power.sh potentially kills laptop disks

If your BIOS is enabling aggressive power management, then I would suggest that that's something you should ask your BIOS vendor about.

Revision history for this message
Ralf Nieuwenhuijsen (ralf-nieuwenhuijsen) wrote :

May i just warn ya all to NOT play the blame-game?

It does sound like it's the fault of the BIOS (and somebody should contact them).

To rescue a hard-drive in distress sounds like something that should have a high-priority (critical?).
Not because it's ubuntu's fault or the bios fault. But because Ubuntu can solve this issue _now_.

How many machines are we talking here? Hundres, maybe thousands?
Help these people out: save those hard-drives!

Suggested priority: critical (data-loss, hardware failure, come on!)
Suggested update-mechanism: security-updates (the complete integrity of the system is in jeopardy)

Just a quick script that checks wether the values are sane and if not default to something sane.
Also, obviously, windows is checking for sane values, although it might be the vendor's fault, ubuntu is going to get the blame.

Hell considering we're destroying hardware, even a fix that would just _tell_ these users to deinstall ubuntu and reinstall windows would be a better situation than trashing their drives within a couple of months.

Revision history for this message
Kamil Páral (kamil.paral) wrote :

Matthew Garrett is right, it seems NOT to be an Ubuntu issue. I managed to get the *same* behaviour under GRUB. In BIOS or GRUB, the harddisk makes "the click" only once, after that it's silent. That's because noone is accessing the drive anymore. But in GRUB, you can browse the filesystem. So if I list some directory, the harddisk audibly "loads" and after a few seconds again "unloads". The difference is, under Ubuntu, someone is always accessing the disk, therefore it unloads/loads constantly over and over again. Windows must automatically set the APM values to another values right after boot (or they might not be accessing/probing the disk all the time, even when idle).

Therefore, the values which everyone complains about are really set from the manufacturer. The question is if it's wrong. Some people may see that unloading disk after 20sec of inactivity is a good thing (less power(?), better security from fall). I can see that hdd manufacturers can set this settings intentionally. The problem is that linux does not allow the disk to stay in the unload mode for even a second. Maybe the culprit is kernel or some program running in the background constantly probing all devices. IF the harddisk stayed unloaded until some read/write activity is needed, all this would be good behaviour.

So there are two problems:

1. Ubuntu is touching the disk all the time. The culprit must be found (e.g. some logging daemons) and the behaviour has to be fixed to be more appropriate for desktop/laptop users. Not only it would extend harddisk life but also extend battery-time on laptops.

2. Until previous bug is fixed, Ubuntu should check for this kind of APM values and tweak them a little bit not to destroy the harddisk in a few months. This is clearly a linux problem (the disk should stay unloaded for some time and it doesn't) so Ubuntu should provide some patch to save customers disks until the whole linux-harddisk-thing is written with more concern of desktop/laptop users and not only servers.

For those who didn't read carefully I sum up: The problem is not in the APM and disk unloading quickly, the problem is in the disk loading up right after unloading.

Revision history for this message
Arthur (moz-liebesgedichte) wrote :

The Load_Cycle_Count on my Laptop's several year old Hitachi drive with Debian installed is 95076488844. That's 95 billion load cycles. And still working. Probably the disks don't wear out that quickly.

Revision history for this message
Chris Moore (dooglus) wrote :

> The Load_Cycle_Count on my Laptop's several year old Hitachi drive with Debian installed is 95076488844.
> That's 95 billion load cycles. And still working. Probably the disks don't wear out that quickly.

>>> 95076488844 / 3 / 365 / 24 / 60 / 60
1004

If 'several' means 3, then that's an average of 1004 loads and unloads per second.

Seems like your load cycle counter is broken.

Revision history for this message
hasan (hassanidin) wrote :

I had used my old hard drive for more than 4 years under Windows. However, after installing Ubuntu on it, it died in a few months. I was wondering if Ubuntu had anything to do with it, now I know it was probably the culprit.

Revision history for this message
Blue (vali-dragnuta) wrote :

Can someone else with this problem post the result from the following :
First,as root:
 on_ac_power ; echo $?
Second :
ps axu |grep apm

Revision history for this message
Julien Olivier (julo) wrote :

I seemed to have this problem too: after only a few months, my hard drive's load_cycle_count was up to 424241, which is about 2/3 of the maximum (from what other people said in comments).

So, I decided to try and run hdparm -B 255 /dev/sda. After running this command, the load_cycle_count increased by 1 unit every 10 seconds, which didn't seem better.

Then, I ran hdparm -B 254 /dev/sda, and now, after 1 hour, my load_cycle_count still hasn't increased...

So, my questions are:
 - Is it normal to have a load_cycle_count of 424241 after a few months ?
 - Is it normal to have this number increase by 1 unit every 10 seconds after running hdparm -B 255 /dev/sda ?
 - Is it normal to have this number NOT increase at all for an hour after running hdparm -B 254 /dev/sda ?
 - What will happen to my battery life time in this last case ?
 - Any advice on how to configure my hard drive so that I can still use it in - say - 2 years, and still be able to use my battery for - say - 1 hour ?

Thanks in advance.

PS: I have already replaced my old hard drive with this one (after 2 years), and I wouldn't like to have to replace this one too anytime soon.

Revision history for this message
Julien Olivier (julo) wrote :

To Blue:

root@julien:~# on_ac_power ; echo $?
0

root@julien:~# ps axu |grep apm
root 7139 0.0 0.1 2988 772 pts/1 R+ 13:47 0:00 grep apm

Revision history for this message
Michiel Sikma (msikma) wrote :

I'd like to second (third, fourth, nth) the importance issue. It's currently on the wishlist, but it seems that this bug is potentially harmful to hardware. This should be considered "high" or "critical" unless we find definitive proof that it isn't very dangerous at all.

Revision history for this message
Blue (vali-dragnuta) wrote :

I intend to investigate later who is calling hdparm to set hard disc power management parameters. I intend to do this by replacing the hdparm binary with a dummy script that
will log it's execution date, parameters and a pstree. I hope by this to find out who and when calls hdparm.
If it is a bios default issue (which I really doubt !) then I will not find any hdparm execution with power management related parameters.

Revision history for this message
Dan Gilliam (geocritter) wrote :

I'm also having the exact same issue on my Toshiba M55; every 5 seconds or so, i hear a tick or a double tick, and my load cycle count is increasing about 2 per minute. Let me know if you guys need any logs or if you want me to try something, and I'll be happy to oblige. :-) Dan

Revision history for this message
Dan Gilliam (geocritter) wrote :

edit that: I meant about 2 per every 10 to 15 seconds, about 4 to 6 per minute (it's slightly variable). I didn't notice whether it was just going up when I had no activity or when it was when i was using it as well.

Revision history for this message
Przemek K. (azrael) wrote :

Maybe we should enable laptop mode by default with CONTROL_HD_POWERMGMT=1 in /etc/laptop-mode/laptop-mode.conf ?
That would probably solve most problems.

Revision history for this message
Michael Gorven (mgorven) wrote :

I found out about this bug from Digg this morning. After investigating, I found that the load cycle on my harddrive was increasing rapidly, both on AC and on battery. This sounds like a fairly serious bug, and should be dealt with quickly. I've made the following changes, which seems to have fixed it (load cycle doesn't increase on AC, and doesn't seem to increase much on DC).

In /etc/laptop-mode-laptop-mode.conf:
CONTROL_HD_IDLE_TIMEOUT=1
LM_AC_HD_IDLE_TIMEOUT_SECONDS=300
LM_BATT_HD_IDLE_TIMEOUT_SECONDS=300
NOLM_HD_IDLE_TIMEOUT_SECONDS=7200
CONTROL_HD_POWERMGMT=1
BATT_HD_POWERMGMT=254
LM_AC_HD_POWERMGMT=255
NOLM_AC_HD_POWERMGMT=255

In /etc/default/acpi-support:
ENABLE_LAPTOP_MODE=true
SPINDOWN_TIME=60

In /etc/acpi/power.sh:
Changed "$HDPARM -B 1 /dev/$drive 2>/dev/null" to "$HDPARM -B 254 /dev/$drive 2>/dev/null"

To Blue:
$ sudo on_ac_power; echo $?
0
$ sudo ps axu | grep apm | grep -v grep
$

Revision history for this message
Przemek K. (azrael) wrote :

I use a workaround with enabling laptop-mode with CONTROL_HD_POWERMGMT=1 and I have discovered that this bug is back after I resume from sleep. When I disconnect the power cord for a moment (to enable laptop mode) and plug it back after a while then the above workaround works again. Weird.

Revision history for this message
Christian Wolf (christianwolf) wrote :

@Michael:

Your workaround looks interesting - can you tell us something about the impact on power consumption? I am currently having the problem that one of my laptops, the Evo N600c, is grilling and toasting its harddrive after I set hdparm -B 200. HD Temperature now is constantly at 50 degrees Celsius, lots of fan activity even with no hard drive access. That leaves me with two impossible options - either I toast my HD or I break it from the load cycles :-(((((

So what does smartctl say about your HD temperature?

Revision history for this message
hasan (hassanidin) wrote :

I also agree that this bug should be rated CRITICAL. If one has to change the hard-drive every so often because of Ubuntu, then Ubuntu would end up being even more expensive than Windows.

Revision history for this message
Michael Gorven (mgorven) wrote :

Smartctl reports a temperature of 49 degrees, which I'm not too worried about. I haven't tested power consumption yet. My settings allow the harddrive to switch off after 5min of inactivity when on battery, and power management isn't completely disabled when on battery. I basically just want to save my drive at the moment -- once this bug gets fixed I'll revert to the (new) default settings.

Revision history for this message
vlowther (victor-lowther) wrote :

For what it is worth, I have enabled laptop-mode on every laptop I install Ubuntu on, and have not had any of the suspend/resume issues that the /etc/default/acpi-support file warns about.

Without having laptop-mode enabled, setting the hard drive to spin down rapidly is just silly -- ext3 will try to flush buffers every 5 seconds, and the kernel will think that tricking writes is OK. As a result, anything you do that dirties buffers will cause the hard drive to spin up.

Does the old issue with suspend/resume and laptop-mode even exist on current distros? I have not encountered it since Edgy (at the latest)...

Revision history for this message
lmierzej (lmierzej) wrote :

I have investigated this issue on two different laptops... both with fresh installation of Gutsy.
On both laptops Load_Cycle_Count gets increased by 1 about every minute, which is very bad...

Invoking 'sudo hdparm -B 255 /dev/sda" solves problem on first laptop. Load_Cycle_Count not increasing for 10 minutes!
Invoking 'sudo hdparm -B 254 /dev/sda" solves problem on second laptop. Load_Cycle_Count not increasing for 10 minutes!

For me this bug is not connected with laptop_mode...
I don't know where in Ubuntu are default hdparm settings...
but even if they are correct they do not work or are not applied...

I would be more then happy to make more tests or supply additional informations...

I think that everyone who can should check his Load_Cycle_Count by invoking 'smartctl -d ata -a /dev/sda | grep Load_Cycle_Count' several times for 5-10 minutes, then 'sudo hdparm -B 255 /dev/sda' and one more 'smartctl -d ata -a /dev/sda | grep Load_Cycle_Count' several times for 5-10 minutes.

Hope this helps...

Can someone change importance of this bug to sane level. 'whislist' is really ridiculous...

Revision history for this message
Baronek (baronek1) wrote :

I can report that sudo hdparm -B 255 /dev/sda solves problem for me
Earlier the HDD was spining up and down like mad, clicking 3-5 times in a minute

And come on, this is NO WISHLIST, this is critical hotfix!!

Revision history for this message
Julien Olivier (julo) wrote :

I wrote a comment 6 hours ago, after I ran hdparm -B 254 /dev/sda. Now, 6 hours later, the load_cycle_count still hasn't increased ! I was expecting it to increase in a slower way, not to stay the same for hours...

Is it normal ? Is it the sign that something is broken ?

Revision history for this message
romassi (romassi1977) wrote :

I think I have the same problem with my 3 years old Acer Aspire 1662wlm...
My notebook has a shining new HD Hitachi 5k100 60 GB, the previous 2 Hitachi HD were broken (the first on January 2007 after more than 2 years using XP and just 6 months of using Kubuntu, the second broken on September 2007)...All the HD has been replaced in warranty (now my warranty is expired) due to an extension I (fortunately) made on 2004.
All my HD "clicked" on idle much much more under Kubuntu than under XP, but I dint't think it could generate a mechanical problem...
For my new Hitachi SMART reports about 3200 load_cycle_count after about 81 Power_on_hours...I thing my brand new HD is not safe with Gutsy and I have no more warranty from Acer to be used; all the suggestions proposed by all of you didn't produce any change on my laptop that still clicks on idle with a constant increasing value of cycle_count.
I gently ask Ubuntu developers to try to find a solution, if a solution exists, for this strange behaviour; I love Kubuntu OS and I don't want to go-back to win

Revision history for this message
Dmitry Pankratov (dremon) wrote :

I've checked this behavior on Mac OS X and Ubuntu Gutsy on MacBook Pro C2D, HDD Fujitsu 160GB.
Under Mac OS X load cycle counter gets increased around every minute, even with external power plugged.

With Ubuntu I've enabled the laptop mode and set CONTROL_HD_POWERMGMT=1 in laptop-mode.conf, and the counter is not incremented anymore with external power source.
With the battery source and laptop mode enabled, HDD spins down periodically when there is no activity, but is not waking up instantly.
When the laptop mode is disabled however, this spindown issue appears under Linux.
I think that the laptop firmware (or hard drive itself) sets aggressive HDD power save mode on startup.

Revision history for this message
Andrew Conkling (andrewski) wrote : A summary of the issue from an Ubuntu developer

Disclaimer: *I* am not said developer. I only link to his blog:
http://www.advogato.org/person/mjg59/diary/82.html

"...by default, we do not alter the hard drive power settings. In other words, the APM settings that your drive is using in Ubuntu are the ones that your BIOS programmed into it when the computer started. This is supported by the fact that people see this issue after resuming from suspend. We don't touch the hard drive settings at that point, so the only way it can occur is if your BIOS or drive default to this behaviour.

[...]

"There's certainly an argument that we should work around BIOSes, but in general our assumption has been that your hardware manufacturer has a better idea what your computer is capable of than we do. If a laptop manufacturer configures your drive to save power at the cost of life expectancy, then that's probably something you should ask your laptop manufacturer about."

Revision history for this message
Martin Wilson (martinmwilson) wrote : Re: default value in power.sh potentially kills laptop disks

Andrew definitely has a good point. And a lot of other people have backed him. It's definitely true that we want the head to park as soon as possible after there is no activity. But for some reason Ubuntu is unparking the head, doing something for a split second, and reparking the head at a constant interval. I think it's this behaviour that really needs to be addressed, not power management.

Revision history for this message
Johnathon (kirrus) wrote :

I think what's coming out from these comments, is that people *want* their BIOS / ACPI settings to be over-ridden, when they're set at values which will destroy hardware fairly swiftly.

Thats _why_ people have constantly requested this issue be made critical, and worked on.

Personally, I have a laptop, currently gathering dust. In the past, I've been thinking about turning it into a webserver... now I'm _very_ glad I never got round to that, as it has long since passed its warrenty (coming on 2 years old now...) and I don't want to have to spend the money replacing the hard-drive.

This does not appear just to be a problem with Ubuntu, but with Windows & OS X as well, although from what I've read online, Windows DOES override the hardware manufactuer's settings to a more sane value, if a little more stressful than a normal desktop machine.

Revision history for this message
Sesivany (jiri-eischmann) wrote : Re: default value in power.sh potentially kills laptop disks

I had the same problem. I tried workarounds written above but nothing helped. Haddisk made one cycle in every second minute when running on battery. Then I turn off laptop mode and now it's OK. And I don't recognize any difference between running with laptop mode and without laptop mode. Battery life is about the same.

Revision history for this message
Blue (vali-dragnuta) wrote :

As I promised, here are the results of the test. I replaced hdparm with a script and logged what happened.
So, here we have the proof that actually the scripts ARE altering the default settings.
<<start>>
Fri Oct 26 01:28:00 EEST 2007 hdparm invoked with parameters -S 4 /dev/sda
...[pstree]
     |-apmd---apmd_proxy---run-parts---laptop-mode---laptop_mode---hdparm---pstree
...
-----------------------------------
Fri Oct 26 01:28:17 EEST 2007 hdparm invoked with parameters -S 244 /dev/sda
init-+-apmd---apmd_proxy---run-parts---laptop-mode---laptop_mode---hdparm---pstree
     |-klogd
     `-rc---S20sendsigs---sleep
-----------------------------------
Fri Oct 26 01:29:33 EEST 2007 hdparm invoked with parameters -S0 /dev/sda
...[pstree]
     |-rc---S20hdparm---S20hdparm---hdparm---pstree
...
-----------------------------------
Fri Oct 26 01:29:37 EEST 2007 hdparm invoked with parameters -S 4 /dev/sda
init-+-NetworkManager
     |-NetworkManagerD
     |-apmd---apmd_proxy---run-parts---laptop-mode---laptop_mode---hdparm---pstree
     |-console-kit-dae---61*[{console-kit-dae}]
     |-cron
     |-dbus-daemon
     |-dd
.....[more pstree cut]
<<< end >>>

All I did was to reenable the acpid and apmd services and reboot... I also mention that on this system on_ac_power returns 255 and the system does not interpret correctly this sittuation and activates a laptop specific on-battery profile(this is another bug) . This is actually a desktop system.

Revision history for this message
Ralf Nieuwenhuijsen (ralf-nieuwenhuijsen) wrote :

About the opinion of the official ubuntu developer.

Yes, it blindly follows what the bios specifies.
But, wait, Windows does not follow what the bios specifies.
The laptop is only supported for windows, hence, it is only tested with windows.

The _expected_ behavior of the hardware manufactoror is that likely that the bios values are ignored (just like they are in windows).

Like I said, stop the blame game. The truth is windows keeps the hard-drive in tact, and ubuntu trashes it.
It destroys it. This is a not a wishlist thingie. The laptop does not officially support linux. Its up to linux to decide wether to support the laptop.

But ubuntu installs WITHOUT A COMPLAINT. This is the real issue. If you want to punish the hardware manufacturor for setting up bad bios values, go ahead. But WARN THE USER.

At this point, not being able to install ubuntu on these laptops would be an _improvement_ of the situation.
Do you really want to kill the harddrives (including all the data loss) of these people because you don't want to solve a problem that is the fault of bad bios settings? Seriously. What ever happend to being a good samaritan. The fact that ubuntu _can_ solve this issue, puts _some_ of the responsibility on Ubuntu.

Revision history for this message
Andrew Conkling (andrewski) wrote :

Just a reminder, for all of us, to keep the Ubuntu Code of Conduct[1] in mind at all times. With this bug getting a lot of attention, that's especially important. I'm sure we can come up with a good solution to this!

[1] http://www.ubuntu.com/community/conduct

Revision history for this message
ubuntu_demon (ubuntu-demon) wrote :

IMHO this bug should get critical status because it's killing people's harddrives.

I previously reported about a problem I had with my harddrive : https://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.22/+bug/151938
Turns out the harddrive was dying. I confirmed it with Samsung's hutil 2.0.3 from the Ultimate Boot CD. Now I am the proud owner of a Western Digital WD2500BEVS. I have had laptop-mode enabled for a long time. Apparantly this caused my harddrive to get a Load_Cycle_Count of 241.493 in 1 year time. This is what probably caused my harddrive problems.

I think we can dissect the bug into the following parts :

* harddrive firmware should use sane defaults for power management (contact your harddrive manufacturer if you don't use laptop-mode and suffer from this problem)

* the BIOS shouldn't set the amount of power management of your harddrive (contact your BIOS manufacturer if your harddrive manufacturer isn't the one to blame)

* aggressive power management settings (set by your harddrive's firmware or your BIOS) should be detected and handled

* laptop-mode should be less aggressive about power management in the meantime you shouldn't enable it

* if the hdparm service is enabled then hdparm should load the settings from /etc/hdparm.conf after resuming frome suspend-to-ram and hibernate-to-disk

* the top causes for hard drive wake up should be found

* smartmontools should be installed on default. smartd should run on default with sane settings hooking into a notifier to notify users
 o if the Load_Cycle_Count is increased with more than 90 cycles within 24 hours
 o if smartctl thinks your harddrive assess your harddrive as not healthy
 o if more than X errors where found during the last self-test

Regarding smartd hooking into a notifier I found the following wiki pages with similar ideas :
 * https://wiki.ubuntu.com/UbuntuDownUnder/BOFs/SMARTMonitoring
 * https://wiki.ubuntu.com/DiskMonitoring

Revision history for this message
ubuntu_demon (ubuntu-demon) wrote :

Also IMHO harddrives shouldn't die within 1 year even if you have enabled aggressive power management settings.

Revision history for this message
Blue (vali-dragnuta) wrote :

There is (almost) no firmware and/or bios issue here. It's the OS's scripts that set insane defaults.
As about aggressive power management settings - let's not forget that a hard drive is a delicate mechanical piece of equipment that spins at 5400 or 7200 rotations per minute.
It is not supposed to be turned on and off every 2 minutes just like your car's engine is not supposed to be turned off whenever you stop at the red light of the semaphore.

Revision history for this message
ubuntu_demon (ubuntu-demon) wrote :

to Blue :

I agree. These laptop-mode defaults seem to be quite insane. But just because you and I suffered from this problem because of laptop-mode doesn't mean there some harddrives might have insane defaults in their firmware (I have no idea how much harddrives would have insane defaults (windows might correct such insane defaults).

Revision history for this message
ubuntu_demon (ubuntu-demon) wrote :

to Blue :

I agree. These laptop-mode aggressive power management defaults seem to be quite insane. You and I suffered from this problem because of laptop-mode. Some harddrives might have insane aggressive power management defaults in their firmware (I have no idea how much harddrives would have insane defaults (windows might correct such insane defaults making these drives less visible).

Revision history for this message
Kamil Páral (kamil.paral) wrote :

You all talk about "insane" settings. They not such bad. The hardware manufacturers know what they are doing. If laptop harddisk go to "sleep" after 30sec of inactivity, there is a reason for that (security, power consumption). And it is perfectly ok. The problem is, the disk is not supposed to be waken up immediately.

Info #1: Today I have witnessed very similar behaviour on two different notebooks running Windows XP. That means, it doesn't have to be true that windows somehow "correct" these settings. It behaved quite same, after 20-30sec of hdd inactivity, the hdd went to sleep. The difference was, under Ubuntu it wakes immediately. Under windows, it was sleeping for several minutes, until some disk activity was needed (some system service or user intervention). *This* is how it is supposed to behave and how hdd manufacturers expect it to be, I presume.

Info #2: Laptop-mode is not enabled by default nor any settings are applied to the disk (as Matthew Garrett said before). So do not blame it. As a matter of fact, my notebook behaves correctly with laptop-mode enabled. It is putting disk to sleep only on battery and it is not waking it up immediately. It is working right like in Windows(!). According to acpi configuration file, laptop-mode is not enabled due to odd hangs on some machines.

What does it all mean? If your harddisk goes to sleep 10 times an hour, always for a few minutes, it's perfectly ok, do the math. That's how the manufacturers supposed it to be. Therefore Ubuntu should not tweak harddisk default settings. Instead, it should detect these "aggressive apm enabled" harddisks (or simply all laptops) and delay flushing intervals and slow down daemons accessing the disk. That's what the laptop-mode does. But it has some hardware compatibility issues. Ok, so let's take only a hardware-independent and non-problematic subset of laptop-mode and enable it on notebooks. It will help their disks a lot.

Simply: Do not touch the disk if you don't have to, Ubuntu. At least on notebooks. That's all.

Revision history for this message
Blue (vali-dragnuta) wrote :

I have _very_ big doubts that any hard disk (even a laptop one) is supposed to spin down after only 20..30 seconds of idle time. If you can sustain this "it's supposed to be that way" with an official manufacturer specification or statement I would greatly apreciate it.
As far as I know, repeated on-off cycles are more stressing to the device than simply letting it run.

Searching about this spinning problem on Western Digital's site I found that some of their drives spin down after 10 minutes of inactivity. This is by far a better default that the one I found is set by the OS's power management scripts. If you look above at my experiment you will find that those scripts execute hdparm -S4 which translates in 20 SECONDS of inactivity before spinning down. This IS insane comparing with 10 minutes. Even more, on the same manufacturer's site I found a document where they say that respinning up a harddisk takes a lot of power (the current peaks at about 1A) which means that if it's needed/done too frequently it basically nulls any power economy you would make by spinning the drive down in the first place...
WD knows this and this is why on some of their products the idle timeout is set to 10 minutes and not to 20 seconds. And I am very sure that the other manufacturers are also aware about this and will not set impossible timeouts that actually do not help them obtain a better medium power consumption. After all, the whole point is to spin the disk down when the probability that the disk will not be needed again too soon is high enough.

Revision history for this message
ubuntu_demon (ubuntu-demon) wrote :

This problem seems even worse than I thought. I'm looking at the Load_Cycle_Count of my new harddrive. I see 17 spindown/spinup cycles within 12 minutes.

The output of various :
$ date
$ sudo smartctl -a /dev/sda | grep Load_Cycle_Count

Sat Oct 27 11:17:28 CEST 2007
193 Load_Cycle_Count 0x0032 200 200 000 Old_age Always - 501

Sat Oct 27 11:24:46 CEST 2007
193 Load_Cycle_Count 0x0032 200 200 000 Old_age Always - 513

Sat Oct 27 11:28:59 CEST 2007
193 Load_Cycle_Count 0x0032 200 200 000 Old_age Always - 518

I turned of my laptop, booted it from ac before generating this output. To proof I'm not running in laptop mode I'm attaching the output from :
$sudo laptop_mode status

Revision history for this message
Kamil Páral (kamil.paral) wrote :

Blue, you have to distinguish between desktop disks and laptop disks. That's a completely different world. I have read a quite nice article, unfortunately only in czech http://www.root.cz/clanky/jak-na-uspavani-disku-v-linuxu/.

It says, that desktop disks sustain about 40 000 spin ups. As opposed to laptop disk, which sustain 300 000 spin ups (600 000 according to words of some reports in here). As you can see, they are build with quite another purpose in mind. They are supposed to spin down/park heads very often, because it helps to survive all the shakes and movements you do with your laptop. I don't know what "good" setting is, but author of the article recommends 30sec delay to spin down as a good value. Further he counts that with hdd spinning up again every 10minutes it can live for 6 years for 24/7. Which is completely acceptable.

What I am trying to say is, that I don't think hardware manufacturers are completely dumb and don't understand their job. They just chose to prefer disk safety to some of it's lifespan. The laptop mode setting might be a little harsh, I am not expert, but I don't consider them insane, when I see manufacturers defaults to be quite similar.

So the problem is elsewhere than you think: Ubuntu either shouldn't allow laptop disks to go to sleep (bad option) or shouldn't wake them up immediately (good option, that's what I am trying to say). The second option is the Windows behaviour on two laptops I have tested.

Revision history for this message
Martin Emrich (emme) wrote :

I just found this bugreport, and I took a look at my stats. My disk (60GB Travelstar 7K100) accumulated ca. 300000 Load Cycle Counts over the last 3 Years. Applying Michaels settings decreased the growth rate massively.

One idea why disks tend to sleep longer on a Windows System: NTFS does not have an atime record which is updated on every read operation. I routinely mount my partitions with "noatime", to let them sleep longer.
And the Windows IO scheduler might by default keep disk writes cached longer, until a read operation has to wake up the disk anyways.

Revision history for this message
jayfre (jayfre) wrote :

I'm using Windows and like to add few things (using a Hitachi Travelstar):

1) Many persons say they have X "Load Cycles" in Y "Years". I don't think that this means much unless you use it 24/7. You should say how many "Load Cycles" in how many "Hours". Using smartmontools is easy.

Mine is: "Load Cycles" - 434211; Hours - 8027. Gives about 54 "Cycles" per "Hour".

2) So how many "Cycles" per "Hour" is "NORMAL"? And the workload? Does using for example Emule increases the "Load Cycles"?

3) The BIOS doesn't allow me change anything about power management. So the solution is to use the "Feature Tool" from Hitachi. This allow you to turn off "Power management".

4) What is "Power Cycle Count" and "Power-Off_Retract_Count" and "Reallocated_Event_Count"?

Thank you!

Revision history for this message
Clément Léger (clem-vangelis) wrote :

I have a Dell Insipron 9400 laptop with a 120gigs Samsung hd , I have this latop for 1 year now and the command : sudo smartctl -a /dev/sda | grep Load_Cycle return that :
225 Load_Cycle_Count 0x0012 040 040 000 Old_age Always - 613491
if I believe the previous comments my hd can die at all time...
the previous fix with sdparm -B 255 /dev/sda doesn't work for me...
i will try to active laptop-mode

Revision history for this message
Clément Léger (clem-vangelis) wrote :

I Forgot to mention that the value Power_On_Hours is equal to :
Power_On_Hours 0x0032 100 100 000 Old_age Always - 348644
but i have my latop for 1 year now and in one year we have 365 day of 24 h thus we have 8760 hours in a year according to Power_On_Hours value my laptop will be running for 39 years ! i believe it's impossible... anyway if the value Load_Cycle_Count is correct i have to backup all my data...

Revision history for this message
Christian Wolf (christianwolf) wrote :

@Martin Emrich:

All my (laptop) systems run with the "noatime,nodiratime" parameter ion /etc/fstab for all partitions.

It makes no difference :-(

BTW I registered a blueprint to turn off atime on desktops as this is completely braindead to have this on by default, as even Linus admits. It costs up to 15% hard drive performance and has no use on a desktop system.

More here (unfortunately somebody removed my link to the rant of Linus on the kernel mailing list about this atime madness in the blueprint :-) )

https://blueprints.launchpad.net/ubuntu/+spec/atimebehaviour

Revision history for this message
jayfre (jayfre) wrote :

So the information provided by SMART is not reliable as we've seen some abnormal values. How can we be certain that this drives failures are because of high "Load Cycles" values?

OT
For users of Windows you can use the "Power Booster" utility from Hitachi's site. With this you can disable power saving functions from inside Windows.

Revision history for this message
Pedro Martinez-Julia (pedromj) wrote : Re: [Bug 59695] Re: default value in power.sh potentially kills laptop disks

Hi,

Worse, a few (or most) laptops have the default behavior of park heads
about 3 or 4 times in a minute. This is fixed in my laptop with "hdparm"
but using "-B254" instead of "-B255".

I added a line in "hdparm.conf" for my disk with "apm = 254". Also
changed "power.sh" to set "-B254" instead of "-B255". It's not needed to
add anything for suspend/hibernate because "power.sh" will be called in
resume.

Regards,

    Pedro

--
Pedro Martínez Juliá
\ <email address hidden>
)| WebLog: http://www.pedromj.com/blog
/ Página web: http://www.pedromj.com
GoogleTalk: <email address hidden>
Socio HispaLinux #311
Usuario Linux #275438 - http://counter.li.org

Revision history for this message
Blue (vali-dragnuta) wrote : Re: default value in power.sh potentially kills laptop disks

Kamil Páral : You are right that laptop disks are much more suitable for increased spin up/down cycles (with about 600k supported by seagate drives) . However, keep in mind that due to another bug added to this one, even desktop computers with desktop drives can end with this kind of settings, AND the 20 seconds idle set by ubuntu's scripts is WAY too small . It makes no sense, the user could just be reading something on the display - this is not idle time. Most likely after another minute he will do something else and the drive will have to be spinned up again. Besides the fact that spinning up takes more energy and nullifies the power saved by stopping the drive, the respin process takes another 4..5 seconds for the usual laptop drive (checked specs on WD for example), and this 4..5 seconds wait every few minutes is annoying for the user.
I fully sustain the iddea of reducing power consumption, but let's do this in a way that really makes sense.
Look what I found on WD's knowledge base regarding external hard disks (these are often targeted to laptop users, and also often use actual laptop drives in usb enclosures :

"The initial power-on process is generally harder on the internal components of a hard drive than spinning for extended periods. However, Western Digital drives are designed to handle either scenario. Most users outgrow their drive before repeated turning on and off becomes a problem. Turning on the drive a few times per day is considered normal usage and should not pose any problems. If a drive is turned on and off excessively on a daily basis, this could affect the longevity of the hard drive’s components."

This is from Western Digital's knowledge base. It refers to external drives, but these are often laptop drives in usb enclosures.

Revision history for this message
Blue (vali-dragnuta) wrote :

Pedro : just parking the heads and not spinning down the platter is not usually a problem. This is usually a good thing and helps minimize damage on the magnetic surface on shocks and vibrations to whick laptop computers are usually exposed to.

Revision history for this message
Przemek K. (azrael) wrote :

@TDB
"3) copy this file to 3 locations:
/etc/acpi/suspend.d/
/etc/acpi/resume.d/
/etc/acpi/start.d/"

I've copied it also to /etc/acpi/ac.d/ - this way it will also be executed when you plug in your power cord.

Revision history for this message
Martin Emrich (emme) wrote : Re: [Bug 59695] Re: default value in power.sh potentially kills laptop disks

Hi!

wolfchri schrieb:
> @Martin Emrich:
>
> All my (laptop) systems run with the "noatime,nodiratime" parameter ion
> /etc/fstab for all partitions.
>
> It makes no difference :-(

It was not meant as a fix for the problem (I have noatime since a long
time), but rather as an explaination for the disk not spinning down very
often. The heads will nevertheless unload too often.

> BTW I registered a blueprint to turn off atime on desktops as this is
> completely braindead to have this on by default, as even Linus admits.

Good Idea. I found the rant myself :)

Martin

Revision history for this message
Gilles Schintgen (shigi) wrote : Re: default value in power.sh potentially kills laptop disks

@ Blue:

As far as I know the Load_Cycle_Count (i.e. this bug) is all about head parking and not about spinning the drive down. And head parking definitely /is/ a problem since the manufacturers usually give a maximum of 300,000 or 600,000 cycles (depending on the drive or its year of construction) in their specifications.

Gilles

Revision history for this message
Thomas Kluyver (takluyver) wrote :

I've just read through this bug, and a little experimentation led me to conclude that I had the same problem. Setting -B254 seems to solve it, although the hard drive temperature is now stable at 49 degrees, which is a bit higher than before.

Noticeably on the comments, a number of people suggest that the importance of this bug should be higher than "Wishlist." (A sentiment that I have to agree with, if this is potentially damaging hardware). Can anyone justify why it should not be set any higher, or has it not been changed simply because no-one knows who should change it?

Revision history for this message
Ryan Thompson (rct86) wrote :

In order to help find all possible ways that the hard drive spindown time could be changed, I have attached the output of the following commands:

sudo find /etc -type f | sudo xargs grep -i ENABLE_LAPTOP_MODE > scripts-that-involve-laptop-mode-setting.txt
sudo find /etc -type f | sudo xargs grep -i hdparm > scripts-that-use-hdparm.txt
sudo find /etc -type f | sudo xargs grep -i laptop_mode > scripts-that-use-laptop-mode.txt
sudo find /etc -type f | sudo xargs grep -i /etc/default/acpi-support > scripts-that-source-acpi-support.txt

I will investigate each of the scripts listed in these files, and determine what changes each one makes, when it makes them, and under what conditions. I will report back, probably later today.

However, since I don't have every package installed, these cannot possibly be full lists. I would recommend that you run the same commands on your own computer and see what files they turn up.

Revision history for this message
Pablo Quirós (polmac1985) wrote :

Also affected by this bug. Like some other people, my problem is solved using a value -B254 instead of 255 (using a Dell Inspiron here).

I think it's nonsense the tag 'Wishlist'. Opened a poll on the forums on this issue: http://ubuntuforums.org/forumdisplay.php?f=135

Revision history for this message
Blue (vali-dragnuta) wrote :

@Gilles Schintgen
It's actually about spin down.
I already proved ( https://bugs.launchpad.net/ubuntu/+source/acpi-support/+bug/59695/comments/78 ) that hdparm is invoked with -S 4 which translates (see hdparm manpage) in "Set the *spindown* timeout for the drive to 20 seconds".
This is the real problem and it's not caused by the drive firmware or the computer's BIOS. It's the operating system's scripts that call hdparm to set unrealistic spindown times.

Revision history for this message
Pedro Martinez-Julia (pedromj) wrote : Re: [Bug 59695] Re: default value in power.sh potentially kills laptop disks

But it's said that a hard drive only supports around 600k Load cycles.

I saw that Ubuntu puts "-B255" to disable APM but it stills do around
3-5 unloads/loads in a minute. With "-B254" it doesn't unload...

Regards,

    Pedro

--
Pedro Martínez Juliá
\ <email address hidden>
)| WebLog: http://www.pedromj.com/blog
/ Página web: http://www.pedromj.com
GoogleTalk: <email address hidden>
Socio HispaLinux #311
Usuario Linux #275438 - http://counter.li.org

Revision history for this message
Gilles Schintgen (shigi) wrote : Re: default value in power.sh potentially kills laptop disks

@Blue

Aren't there two slightly different but related problems?

The first one is about a nearly inaudible clicking which happens when the heads are unloaded and which is the reason I filed this report (since it'd be killing my drive, slowly but inevitably). It doesn't cause any noticeable delays when the heads are loaded again.

The second one is true spindown which causes annoying delays when the drive is spun up again. (And which also causes wear and tear on the mechanical parts of the drive.) Wouldn't that be bug 17216?

Regards,

Gilles

Revision history for this message
Reuben Firmin (reubenf) wrote :

> I confirm this and more : same behaviour on a _desktop_ computer. This because on that desktop on_ac_power returns nonzero and the system thinks it's running on batteries.

I don't think this is necessarily true (although I haven't looked at the script). on_ac_power is 255 on my desktop, but Load_Cycle_Count does not go up over time unless I explicitly set apm to a low value (otherwise it generally seems to be off.)

*However*, there is periodic disk rumbling (3-4 times a minute) on my machine, which is what drew me to this bug in the first place. I've tried killing off all non-essential daemons, and still I get the same behaviour. Haven't tried single user mode yet, but that's my next test.

Revision history for this message
Blue (vali-dragnuta) wrote :

Gilles,
I think the root of the both evils is common :)

On a desktop computer, spinning down and then spinning up the hard disk produced the same annoying "clank". If I had a newer and quieter hard drive on that machine
I could have missed this problem ... (or at least realize it only later by the spinup delay).Because the noise I found it just about an hour after installing the new release on this machine :)
I myself solved the problem by setting hdparm.conf and disabling apmd and acpid (unneeded on that machine). So I'm not affected by this problem any more myself.

Now, we must make the difference between the following parameters :
1.Start/Stop Count and
2.Load/Unload Cycle Count

The first counts how many times the hard drive entered sleep mode OR was fully stopped/powered off.
The second one counts the number of times the heads were parked in the landing area. You can get the heads to go to the landing area and keep the platters spinning, but you cannot
spin down without parking the heads. So, wherever you spin down the drive both of those smart parameters are incremented. When the drive is just parked, only Load/Unload Cycle Count is incremented.
While a lot of parking is not bad, a lot of start/stops are bad.
The <<hdparm -S >> in the power management scripts that I'm pointing my finger at controlls the spinup/spindown and not just the parking of the heads. And the default timeout for that is not only uninspired, but potentially dangerous. This is what actually has the greatest potential to kill the drive prematurely. So, in your smartctl output look for a high start/stop count , not for a high load/unload count .
These are the values for my laptop that still runs Dapper :

  4 Start_Stop_Count 0x0012 100 100 000 Old_age Always - 749
 12 Power_Cycle_Count 0x0032 100 100 000 Old_age Always - 386
193 Load_Cycle_Count 0x0012 036 036 000 Old_age Always - 646281

The hard drive is only about 1 year old. I'm not worried about Load_Cycle_Count (which is way over 600k ). I would worry about a high Start_Stop_Count .

Revision history for this message
Pedro Martinez-Julia (pedromj) wrote : Re: [Bug 59695] Re: default value in power.sh potentially kills laptop disks

749 times is not a lot of start/stop count but 600k is huge for parking.

Regards,

    Pedro

--
Pedro Martínez Juliá
\ <email address hidden>
)| WebLog: http://www.pedromj.com/blog
/ Página web: http://www.pedromj.com
GoogleTalk: <email address hidden>
Socio HispaLinux #311
Usuario Linux #275438 - http://counter.li.org

Revision history for this message
Blue (vali-dragnuta) wrote : Re: default value in power.sh potentially kills laptop disks

Parking is not bad and should not have side effects.

On a new system ( just a few days old) running another OS Load_Cycle_Count is 3317.
This parking means just moving the heads away, it does not stress the disk in any way .
 The spindown/spinup however, does (and does not help save energy if it is done too quickly )

Revision history for this message
Martin Emrich (emme) wrote :

I just found some manufacturer specs for my Disk:

http://www.hitachigst.com/tech/techlib.nsf/techdocs/53989D390D44D88F86256D1F0058368D/$file/T7K60_sp2.0.pdf
For the load/unload specs, see page 40f. It is specified to a minimum of 300000 load/unload cycles, so I'm very near to EOL.
My disk stats:
martin@gwaihir:~$ ./disk-stats -y
PM-related Hard disk health:

                      Load/Unload cycles : 270250 of 300000 (90.08% of life)
    Power-Off retract (Emergency unload? : 27 of 20000 (0.14% of life)
                         Power-On cycles : 3582
          Start/Stop (PM Spindown) count : 10427 of 300000 (3.48% of life)
                          Power-On hours : 6343 of 20000 (31.71% of life)
            Temperatures during lifetime : 13 to 47, manufacturer limits: 5 to 55 (°C)
     Average Load/Unload cycles per hour : 42.606

I have written a little hackish script to generate this, it is attached for anyone feeling the urge to present their stats here, too. (needs smartctl)

Ciao

Martin

Revision history for this message
Gilles Schintgen (shigi) wrote :

@Blue

Parking does not stress the disc's surface but rather the head movement mechanics. Remember, parking must be fast enough to protect against imminent damage. (Consider for example HP's HDAPS technology.) Thus excessive load/unload cycles *are* stressful and *will* damage the drive. Why else would the manufacturers specify minimum values in their data sheets?

Regards,

Gilles

Revision history for this message
lukk (lukk-pl-gmail) wrote :

Hi.
Somethin from my smartctrl:
    3 Spin_Up_Time 0x0007 100 100 025 Pre-fail Always - 2752
    4 Start_Stop_Count 0x0032 099 099 000 Old_age Always - 1013
    9 Power_On_Hours 0x0032 099 099 000 Old_age Always - 707090
  12 Power_Cycle_Count 0x0032 100 100 000 Old_age Always - 601
225 Load_Cycle_Count 0x0012 001 001 000 Old_age Always - 1230345

The hdd is Samsung HM-120JI, have 14 months. Often running 24/7. 1230345 > 600k like for me. Increase was high. Stoped with -B254, but temperature increased.
What is more dangerous - high Load_Cycle_Count VS -B254, higher temperature and shock-temper on that setting?

Revision history for this message
Pedro Martinez-Julia (pedromj) wrote : Re: [Bug 59695] Re: default value in power.sh potentially kills laptop disks

Hi,

In your case (24x7), you should use a value for "-B" that can increase
the life of your hard drive having a reasonable temperature. My hard
drives tells (through smartctl) 41ºC and 13/51 for actual and min/max
temperatures. I'm using "hdparm -B254" since yesterday because it
reached 400k loads.

I don't know any case of certain hard drive broker due to load/unload
cycle but reading specifications I found that the drives can support
about 300k loads and can effort a million loads without crashing but
with no warranties.

I didn't find any execution of hdparm in the start-up scripts, the
problem should be in BIOS or kernel. The hard drive can have default
configuration to get a balance between its capabilities (temperature,
loads, spins, etc), this may be configured by BIOS in the POST or by the
drive firmware in its reset.

Regards,

    Pedro

--
Pedro Martínez Juliá
\ <email address hidden>
)| WebLog: http://www.pedromj.com/blog
/ Página web: http://www.pedromj.com
GoogleTalk: <email address hidden>
Socio HispaLinux #311
Usuario Linux #275438 - http://counter.li.org

Revision history for this message
Blue (vali-dragnuta) wrote : Re: default value in power.sh potentially kills laptop disks

I didn't find any execution of hdparm in the start-up scripts,

How did you search ? Because in my case there are a FEW executions.

Revision history for this message
Pedro Martinez-Julia (pedromj) wrote : Re: [Bug 59695] Re: default value in power.sh potentially kills laptop disks

Init system calls hdparm script but my "hdparm.conf" had no-section.
I've added one for adding "-B254".

Using "rgrep -i *" in "/etc" can tell you a lot of things but if you
want more, for example, change hdparm binary with a wrapper script that
calls real hdparm and logs its execution (date >> /var/tmp/hdparm.log).

Regards,

    Pedro

--
Pedro Martínez Juliá
\ <email address hidden>
)| WebLog: http://www.pedromj.com/blog
/ Página web: http://www.pedromj.com
GoogleTalk: <email address hidden>
Socio HispaLinux #311
Usuario Linux #275438 - http://counter.li.org

Revision history for this message
Blue (vali-dragnuta) wrote : Re: default value in power.sh potentially kills laptop disks

I already did that and I found that hdparm is executed a lot of times just during one boot process :

https://bugs.launchpad.net/ubuntu/+source/acpi-support/+bug/59695/comments/78

Revision history for this message
Pavel Šefránek (pavelsefranek) wrote :

I tried two distros: Fedora and openSUSE. I have a TOSHIBA MK8037GSX hard disk. In Fedora by default, there is something around 6 Load/Unload cycles per hour. In openSUSE, after a hour of an uptime there was only 1 Load/Unload!!! So, this looks like very ubuntu specific and should be worked out as soon as possible.

Revision history for this message
Pedro Martinez-Julia (pedromj) wrote : Re: [Bug 59695] Re: default value in power.sh potentially kills laptop disks

As you can see that hdparm executions are related to laptop_mode, not
directly to start-up. If Ubuntu can't identify your AC status is another
bug, not related to "power.sh".

Regards,

    Pedro

--
Pedro Martínez Juliá
\ <email address hidden>
)| WebLog: http://www.pedromj.com/blog
/ Página web: http://www.pedromj.com
GoogleTalk: <email address hidden>
Socio HispaLinux #311
Usuario Linux #275438 - http://counter.li.org

Revision history for this message
Pedro Martinez-Julia (pedromj) wrote :

Hi,

Please, can you post kernel versions and hdparm parameters used in
init-scripts?

Detailed information about hdparm calls during start-up and while
changing power source in OpenSUSE and Fedora could be very interesting.

Regards,

    Pedro

--
Pedro Martínez Juliá
\ <email address hidden>
)| WebLog: http://www.pedromj.com/blog
/ Página web: http://www.pedromj.com
GoogleTalk: <email address hidden>
Socio HispaLinux #311
Usuario Linux #275438 - http://counter.li.org

Revision history for this message
Mathieu Marquer (slasher-fun) wrote : Re: default value in power.sh potentially kills laptop disks

About the "criticals" value for Load/Unload Cycles, Momentus 7200.2 spec sheet only says "> 600,000" (http://www.seagate.com/docs/pdf/datasheet/disc/ds_momentus_7200_2.pdf)
So since I'm already at 50000 after 2 months with this computer, I had to apply the hdparam -B254 parameter, and now the Load/Unload Cycles increases really slower than it used to.

I also think that this bug should be marked as critical, since it is dangerous for the hardware part of the computer.

Revision history for this message
matehortua (matehortua) wrote :

Im on a DELL INSPIRON 6400 this my hard drive:

Device Model: SAMSUNG HM120JI
Serial Number: S0YPJ10P326665
Firmware Version: YF100-15
User Capacity: 120,034,123,776 bytes

ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_FAILED RAW_VALUE
    3 Spin_Up_Time 0x0007 100 100 025 Pre-fail Always - 2752
194 Temperature_Celsius 0x0022 097 070 000 Old_age Always - 47
225 Load_Cycle_Count 0x0012 094 094 000 Old_age Always - 67448 ******

Im using UbUNTU 7.10
Linux ubuntu 2.6.22-14-generic #1 SMP Sun Oct 14 23:05:12 GMT 2007 i686 GNU/Linux

Hope this changes from whishlist to critical bug
tnx

Revision history for this message
Fernán González (fernangonzalez) wrote :

I am very concerned about this issue. I use Ubuntu on my laptop as my primary OS and I work with it. Even if we all back up in case something happens with our hard drives, this issue is serious enough. I wouldn't use "wishlist" for something that breaks hardware, especially when it's been confirmed and this bug profile has been logged in Launchpad for over a year. I can't recommend my friends to install Ubuntu on their laptops knowing there's a bug like this.

Revision history for this message
Pavel Šefránek (pavelsefranek) wrote :

Pedro Martínez Juliá: there is a fedora-related discussion (https://www.redhat.com/archives/fedora-devel-list/2007-October/msg02258.html) about this -- as of this (https://www.redhat.com/archives/fedora-devel-list/2007-October/msg02260.html) it seems fedora doesn't change this setting no matter if you're plugged or not.

I'll try to find some opensuse settings of this, but now i have no idea where to search. But opensuse seems to do no Load/Unload cycles except for at system boot.

Revision history for this message
saserr (saserr) wrote :

Just to add some interesting facts to discusion:
* my load/ unload count is at 141831
* my power on hours is 11119, i was using linux for maybe 95% of time
That means that my average load/unload count per hour was 12, i think that is normal, around one every 5 minutes.
But when i checked yesterday i was averaging 3 loads/unloads per minute so I am pretty sure this bug has to do something whit gutsy or feisty. Just my two cents.

Revision history for this message
ubuntu_demon (ubuntu-demon) wrote :

My harddrive started to slowly die when at a Load_Cycle_Count of 200.000 after 10 months of use (Feisty and a little bit of Gutsy).

The reason I’m estimating to watch out for values above 90 per day is because it will guarantee that your Load_Cycle_Count is less than 100.000 in three years : 90 * 365 * 3 = 98550 Which almost guarantees that your harddrive won’t die during the first three years due to a high Load_Cycle_Count.

I'm blogging about this bug at : http://ubuntudemon.wordpress.com which is subscribed to planet.ubuntu.com

Revision history for this message
Pavel Šefránek (pavelsefranek) wrote :

So in opensuse this behavior is possibly controlled by the pm-utils framework (http://en.opensuse.org/Pm-utils). I found only one file with hard disk related settings (/usr/lib/pm-utils/power.d/laptop-tools/. I'll attach it, but there is nothing to do with hdparm settings. Maybe opensuse the same way as fedora doesn't change BIOS defaults. Kernel version: 2.6.22.9-0.4-default, in Fedora it was something around 2.6.23, possibly 2.6.23.1-31.fc8 (I haven't use fedora anymore)

Revision history for this message
karlbowden (karlbowden) wrote :

I have a 4 month (approx) old Dell XPS M1210 running Gutsy now. It has never run anything other than Ubuntu.
193 Load_Cycle_Count 0x0012 062 062 000 Old_age Always - 386280

My biggest concern with this not being marked as critical is that I have changed EVERY setting in the bios and it still increases at 4 per minute. And there are no settings in the gnome power management preferences.

If I do not at least get a standard control to reduce this rate I dont think I will have any choice but to keep trying distros until I find a more hdd friendly one. But then again, I have still not seen it do any damage to any old hard drives i've been running though.

I'm happy enough adding in extra power management scripts as long as it dosent get interfered with on a apt-get upgrade.

Revision history for this message
lukk (lukk-pl-gmail) wrote :

So, my HDD with 1230345 Load_Cycles_Count can die young? (in every moment I must be ready for his last... click?). Even with low Power_Cycle_Count, just because I use my Ubuntu running often 24/7?

Revision history for this message
Pavel Šefránek (pavelsefranek) wrote :

karlbowden: Have you tried one of these two commands?
hdparm -B255 /dev/sda
or hdparm -B254 /dev/sda

You must try 255 or 254 because every disk wants another option to decrease amount of Load_Cycles.

Revision history for this message
Bart Samwel (bart-samwel) wrote :

@Blue:

Regarding this: "Even more, on the same manufacturer's site I found a document where they say that respinning up a harddisk takes a lot of power (the current peaks at about 1A) which means that if it's needed/done too frequently it basically nulls any power economy you would make by spinning the drive down in the first place..."

I don't think this picture is entirely accurate. Typical drives draw ~1 W while spinning without reading/writing, ~2 W while reading/writing, and ~2-4 W while spinning up. The break-even point depends on the exact values and the spin-up speed, although I guess that the total amount of power required to spin up will be somewhat constant (i.e., a longer spin-up will require a lower wattage). I did some measurements on this a while ago, published here:

http://www.linuxjournal.com/article/7539

You can see from the chart that spinning this particular drive down *every* 12 seconds already yields significant savings. This suggests that the break-even point lies somewhere around 6-8 seconds of spun down time.

Now, regarding the "insane" -S4 setting for laptop mode: this setting is intended for battery mode only, and only on laptop drives. Let's do the math. Assuming you spin down the drive *only* while you're on battery (which is when it matters), and you get one spindown every minute. Assume the laptop lasts for 5 hours on every charge (a high estimate for typical laptops) and the battery has a lifetime of 1200 discharge-charge cycles (again, a high estimate). Then you have 1200 * 5 * 60 = 360000 cycles before you have to replace your first battery, and then you can take another 800 cycles before the 600000 spindown mark is reached.

Alternatively, consider when you use battery mode for exactly 5 hours a day, every day (a quite extreme situation). That's 300 spindowns per day, or 300*365 = 109500 spindowns per year. That yields a lifetime of 5.48 years (again assuming a lifetime rating of 600000 spindowns).

Note that one spindown per minute is a very high average, you'll almost never hit that: usually, you have more extended periods of continuous drive usage (when you're doing stuff), as well as more extended periods of no drive usage (while you're reading stuff or editing a document/file). Also, five hours of on-battery usage on average *every day of the week* for years in a row is a very high estimate (I guess most laptops get used fully for either 5 or 2 days a week, not seven). I therefore think that -S4 is a pretty safe setting for on-battery usage. Also, setting it higher will cut into your power savings very fast. Set it to -S12 and your drive will probably not spin down very often at all, which means that you can just as well turn laptop mode off.

Anyway, I think that any power management settings which make a drive load/unload once every minute *all the time* are doomed to kill drives. No need to blame this problem on the -S4, which is for a very special use case (on battery) only.

Revision history for this message
Pedro Martinez-Julia (pedromj) wrote : Re: [Bug 59695] Re: default value in power.sh potentially kills laptop disks

You should backup all your data!

It's not sure to crash but you should know that number is over the
maximum taken from Hitachi specification about Load/Unload. It says that
300k cycles are bonded but they tested over 1000k loads (not cycles).

Regards,

    Pedro

--
Pedro Martínez Juliá
\ <email address hidden>
)| WebLog: http://www.pedromj.com/blog
/ Página web: http://www.pedromj.com
GoogleTalk: <email address hidden>
Socio HispaLinux #311
Usuario Linux #275438 - http://counter.li.org

Revision history for this message
Christian Schürer-Waldheim (quincunx) wrote : Re: default value in power.sh potentially kills laptop disks

My notebook (Dell D620) is not running on batteries, although the Load_Cycle_Count of the hard disk increased by 420 within a day (it was running for only 6 hours during this period).

My notebooks is 14 months old and the HD has a Load_Cycle_Count of 13570.

Revision history for this message
Dan Gilliam (geocritter) wrote :

I don't understand the argument that this is only "on batteries". I generally have my laptop plugged in, and my counts are increasing astronomically (the once every 5-6 seconds thing). It doesn't seem to make a difference whether it's plugged in or not.

I'm switching back to Windows until this is fixed...if anybody wants any info from my system, let me know and i'll reboot into it. But i can't risk the harddrive.

Revision history for this message
Bruce Cowan (bruce89-deactivatedaccount) wrote :

This is not a forum, this is a bug tracker. Please do not comment unless you have to from now on.

My Desktop doesn't have this issue.

Revision history for this message
Blue (vali-dragnuta) wrote : Re: [Bug 59695] Re: default value in power.sh potentially kills laptop disks
Download full text (5.3 KiB)

On Sun, 2007-10-28 at 13:26 +0000, Bart Samwel wrote:
> @Blue:
>
> Regarding this: "Even more, on the same manufacturer's site I found a
> document where they say that respinning up a harddisk takes a lot of
> power (the current peaks at about 1A) which means that if it's
> needed/done too frequently it basically nulls any power economy you
> would make by spinning the drive down in the first place..."

-------- I think it's a considerable effort due to the fact that they
needed to create a special "technology" to make it easier on the
drive :) Of course this depends on the drive speed too.

>
> I don't think this picture is entirely accurate. Typical drives draw ~1
> W while spinning without reading/writing, ~2 W while reading/writing,
> and ~2-4 W while spinning up. The break-even point depends on the exact
> values and the spin-up speed, although I guess that the total amount of
> power required to spin up will be somewhat constant (i.e., a longer
> spin-up will require a lower wattage). I did some measurements on this a
> while ago, published here:
>
> http://www.linuxjournal.com/article/7539
>
> You can see from the chart that spinning this particular drive down
> *every* 12 seconds already yields significant savings. This suggests
> that the break-even point lies somewhere around 6-8 seconds of spun down
> time.
>
> Now, regarding the "insane" -S4 setting for laptop mode: this setting is
> intended for battery mode only,

  But it gets activated for desktop where battery status cannot be
determined,too. And this is bad. Also, I don't find smart to try to
bring down the disk every 20 seconds because it is very likely that you
will have to respin it very, very soon later because of user activity or
system activity (there are a lot of files that are open and appended at,
varios logs, xsession-errors and so on). I'm not sure that we should
bring the power management to extreme. Please set -S4 to your laptop
and let it idle. You will see that anyway the hard disk stops and
respins every 1..2 minutes.

> and only on laptop drives. Let's do the
> math. Assuming you spin down the drive *only* while you're on battery
> (which is when it matters), and you get one spindown every minute.
> Assume the laptop lasts for 5 hours on every charge (a high estimate for
> typical laptops) and the battery has a lifetime of 1200 discharge-charge
> cycles (again, a high estimate). Then you have 1200 * 5 * 60 = 360000
> cycles before you have to replace your first battery, and then you can
> take another 800 cycles before the 600000 spindown mark is reached.
>
> Alternatively, consider when you use battery mode for exactly 5 hours a
> day, every day (a quite extreme situation). That's 300 spindowns per
> day, or 300*365 = 109500 spindowns per year. That yields a lifetime of
> 5.48 years (again assuming a lifetime rating of 600000 spindowns).
>
> Note that one spindown per minute is a very high average, you'll almost
> never hit that: usually, you have more extended periods of continuous
> drive usage (when you're doing stuff), as well as more extended periods
> of no drive usage (while you're reading stuff or editing a
> document/file). Also, five h...

Read more...

Revision history for this message
Bart Samwel (bart-samwel) wrote : Re: [Bug 59695] Re: default value in power.sh potentially kills laptop disks
Download full text (4.8 KiB)

Blue wrote:
>> Now, regarding the "insane" -S4 setting for laptop mode: this setting is
>> intended for battery mode only,
>
> But it gets activated for desktop where battery status cannot be
> determined,too. And this is bad.

ACK, definitely.

> Also, I don't find smart to try to
> bring down the disk every 20 seconds because it is very likely that you
> will have to respin it very, very soon later because of user activity or
> system activity (there are a lot of files that are open and appended at,
> varios logs, xsession-errors and so on).

This is what laptop mode is for. It makes sure that writes _do not_ get
sent to disk too often. Otherwise, you will get spindowns every 30
seconds because of atime updates. I routinely get multiple-minute
spindowns. However, it shouldn't be used when you're not on battery. And
then the disk shouldn't spin down, or even park its disk too often. The
problem is that this does happen now, without the
disk-activity-avoidance tweaks provided by laptop mode. Which is exactly
when the -S4 setting is _not_ applied. So any criticism of the -S4
setting is not relevant to this bug report at all.

> I'm not sure that we should bring the power management to extreme.
> Please set -S4 to your laptop and let it idle. You will see that anyway\
 > the hard disk stops and respins every 1..2 minutes.

If you don't enable laptop mode, yes, then this happens. That's why -S4
should only be enabled in combination with laptop mode.

>> Anyway, I think that any power management settings which make a drive
>> load/unload once every minute *all the time* are doomed to kill drives.
>> No need to blame this problem on the -S4, which is for a very special
>> use case (on battery) only.
>
> Anyway, it seems that we have actually more problems. It is the
> Load/Unload period -which we should address by putting a hdparm -B with
> an appropriate value, and the spindown timeout which we should address
> so that it really makes sense and does not creates a situation where
> even let idle the system will get spinned/downspinned every minute or
> two. If someone really needs that kind of power saving then he/she
> should consider solid state disks which are more appropriate for
> economy.

My concern is that you seem to couple the -B value with the -S4 value
here. The -S4 setting is only applied by laptop-mode-tools when two
conditions are met: (a) laptop mode is enabled (which is not the case by
default), and (b) the laptop is on battery (which is not mentioned
anywhere in this bug report as being a condition of the problem
occurring). AFAICT this bug report concerns the -B value, not the -S
value. The -S4 value is very sensible when laptop mode is enabled. I
wouldn't want you people starting to fiddle with it to fix this bug
report when it, in fact, won't help, and will only throw away the baby
with the bath water for laptop mode users. If you go and tweak the way
-B settings are applied, be my guest. It seems to be the proper fix for
this bug. But PLEASE don't mix it up with this setting, which isn't even
applied in the situations that this bug report is about.

> The third problem would be that on systems...

Read more...

Revision history for this message
Saivann Carignan (oxmosys) wrote : Re: default value in power.sh potentially kills laptop disks

I would like to notice that my laptop does have a Power_Cycle_Count near to 1 per minute on Linux, but also on Windows, I don't see any difference..

And I have a desktop computer which seems to have a Power_Cycle_Count smaller than 1 per hour.

I don't know if this problem really affects some computers which suffer from bad detection, but it's not my case.

Revision history for this message
Guy Widloecher (guy-widloecher) wrote :

I confirm on 2 DELL laptops, the 1st one 18 months old with Load_Cycle_Count around 900000, the 2nd one 1 month old with 25000. I just applied the hdparm.conf workaround as explained several time above.

This issue in "Wishlist" is inapproprate. It should be considered as "high" or "critical".

Revision history for this message
Saivann Carignan (oxmosys) wrote :

Guy Widloecher : Can you calculate how many Load Cycle Count you have within one minute and copy it there?

Revision history for this message
Guy Widloecher (guy-widloecher) wrote :

Response to Saivann Carignan : the exact value is 870009

I noticed that the rate was around 1 per minute before stopping it by editiing hdparm.conf.

Checking : the laptop was bought beginning of 2006. It is always up or so. 870009 at the rate of 1 per minute (1140 per day) means an uptime of 600 days. Is seems to be coherent with its age.

Revision history for this message
Saivann Carignan (oxmosys) wrote :

I tested my laptop again with Windows XP and got really different result this time, Windows just does a Load_Cycle_Count each 3 minutes. I don't know why it's different now but here it seems that yes, ubuntu does a Load_Cycle_Count very more oftenly than Windows. More, Ubuntu still get around 1 Load Cycle per minute when the laptop has been booted while it was plugged ( not on battery ). Is that bad? According to the fact that a laptop maximum SMART attribute is 900000, I would say that yes.. something is probably wrong.

However, my Desktop Dell PC still doesn't get a Load_Cycle_Count in one hour, that seems completely normal. So the problem doesn't appear in any PC.

Is there a HardDrive expert who would be able to confirm if the ubuntu behavior is or isn't correct?

Revision history for this message
puccha (yuri-schaeffer) wrote :

I have the same problem with my laptop drive.

=== START OF INFORMATION SECTION ===
Device Model: ST9160821AS
Serial Number: 5MA0NKXS
Firmware Version: 3.ALB
User Capacity: 160,041,885,696 bytes
...
193 Load_Cycle_Count 0x0032 052 052 000 Old_age Always - 96509

Laptop is 5,5 months old, I guess that's a spindown of once every 30 seconds.

Revision history for this message
Julius (julien-willem) wrote :

I can confirm this on an Acer Aspire 1642 WLMi.

I got about 80 to 100 cycles per hour.

This bug should be "critical" !!!

I tried with Archlinux... Results : 1 cycle per hour. Oo

Revision history for this message
karlbowden (karlbowden) wrote :

@Paval:

Well.... Measuring 10 mins at a time, all measured with the ac adaptor connected.
Straight after boot: 40 / 10min
hdparm -B255 /dev/sda: 40 / 10min
hdparm -B254 /dev/sda: 0 / 10min

Revision history for this message
Christian Vogler (christian-vogler) wrote :

I get numbers similar to karlbowden on an Asus G1S-A1 laptop with AC connected, for a Hitachi HTS541616J9SA00. After 3 months of use the load cycle count is already up to 65,000, so I agree that the bug should be marked as critical.

Revision history for this message
Przemek K. (azrael) wrote :

I have a HP Compaq nx6325 laptop and my Hitachi HTS541080G9SA00 hard drive has 94066 load/unload cycles after 11 months of using Ubuntu with it.
Don't blame this bug on the BIOS - every ordinary user will tell you that Windows didn't hurt their hard disk and it is Ubuntu that killed it. That's why this bug's priority should be marked at least as high.
Also try to find similar bugs in other linux distributions, or even file them if they suffer from similar problem.

Revision history for this message
Bruce Cowan (bruce89-deactivatedaccount) wrote :

This is getting ridiculous, this is the 149th comment. Please refrain from discussing this bug or "confirming" it, it has been confirmed enough.

Leave all discussions to the forums, not a bug report. Don't ask other "me too" people questions here.

Revision history for this message
Johnathon (kirrus) wrote :

It does not matter that the bug is getting confirmed multiple times. Better getting lots of "me too"s than the bugsquad having to find and mark hundreds of duplicate reports.

To whomever is triaging / working on this one, (if anyone is working on this bug), what do you want to happen next? Do you need more information?
If not, is there a developer who is willing to take charge of this bug?

Revision history for this message
keatliang2005 (keatliang2005) wrote : ASK for PROPER and detail solution

can any one suggest a ULTIMATE and detailed solution, because i see a lot of comment here and i can't understand at all
 thx

Revision history for this message
Christian Wolf (christianwolf) wrote : Re: default value in power.sh potentially kills laptop disks

@keatliang2005

I have summarized the hdparm workaround here, should work for all notebooks, not only on the NX6325:

http://vale.homelinux.net/wordpress/?p=199

Revision history for this message
Gronfilo (gronfilo) wrote :

Wolfrichi:

I am afraid that hdparm -B 254 or 255 do not work for every laptop. I have a Dell latitude c840 with a Hitachi travelstar DK23EA-30 that is completly unresponsive to any hdparm -B setting I have tried.

It doesn't even allow me to change default APM levels with the Hitachi feature tool boot disk.

Revision history for this message
ramas (slocascio) wrote :

Just some more reporting about this issue:

- The command "sudo hdparm -I /dev/sda" shows this line about APM:

Advanced power management level: unknown setting (0x80fe)

The 0xfe byte is the 254 value I set whith the -B command in hexadecimal, but i do not understand the 0x80 byte and why it tells "unknown setting".

- The command " sudo smartctl -d ata -a /dev/sda" shows also other values, some of them very high and incrementing:
Raw_Read_Error_Rate, Seek_Error_Rate, Unknown_Attribute (with ID# 190), Hardware_ECC_Recovered

Reading in internet I found not so clear info about them; for example, the Raw_Read_Error_Rate here says lower is better:
http://en.wikipedia.org/wiki/Self-Monitoring%2C_Analysis%2C_and_Reporting_Technology
while here (linked from the above wikipedia page) it says the opposite:
http://www.ariolic.com/activesmart/smart-attributes/raw-read-error-rate.html

how can we have more complete information about these parameters?

Revision history for this message
Gronfilo (gronfilo) wrote :

Well, regarding the System I mentioned before (Latitude C-840 with Hitachi travelstar Dk23EA-30) That was completly unresponsive to hdparm settings I can now confirm that under Windows 2000 the load unload cycles in this equipment are not eliminated but greatly diminished.

So may be Ubuntu is not causing this behavior but there seems to be something in Ubuntu that is exacerbating the problem to where it becomes unbearable.

Since I have not been ablo to find a workaround It seems that I will have to forget Ubuntu as a workable alternative for the time being. I really hope this is given the attention it deserves and solved.

I am very dissapointed that the bug is still listed in the whislist category.

Revision history for this message
Bruce Cowan (bruce89-deactivatedaccount) wrote :

No wonder this has had no attention, it's impossible to glean anything from this ridiculous number of comments. I have no choice but to unsubscribe.

I do however ask that people not comment on this further unless absolutely necessary.

Revision history for this message
Ralf Nieuwenhuijsen (ralf-nieuwenhuijsen) wrote :

Could part of the problem, the frequest disk writes, have anything to do with tracker?
What happens when you do a "killall trackerd"?

Revision history for this message
Daniel Hahler (blueyed) wrote :

I've tried to summarize the issue(s) found here in a wiki page. I think it's easier to handle solutions for this over there:
https://wiki.ubuntu.com/DanielHahler/Bug59695

Another option might be to create a new bug from scratch and duplicate this one, but I think for now the wiki is the best thing to do.

Please feel free to edit/add to the page.
(I'm not affected by this issue myself and am uncertain how to attack it.)

Revision history for this message
Brian Ealdwine (eode) wrote : Re: [Bug 59695] Re: default value in power.sh potentially kills laptop disks

I'm 99% sure that the problem lies not (so much) in the aggressive APM,
but in the combination of the aggressive APM and some spurious constant
disk activity. If the disk activity weren't there, it wouldn't be so
much of an issue, and if the APM weren't so aggressive, it wouldn't be
so much of an issue. I'll notate this on the wiki.

-b

On Tue, 2007-10-30 at 03:08 +0000, dAniel hAhler wrote:
> I've tried to summarize the issue(s) found here in a wiki page. I think it's easier to handle solutions for this over there:
> https://wiki.ubuntu.com/DanielHahler/Bug59695
>
> Another option might be to create a new bug from scratch and duplicate
> this one, but I think for now the wiki is the best thing to do.
>
> Please feel free to edit/add to the page.
> (I'm not affected by this issue myself and am uncertain how to attack it.)
>

Revision history for this message
Bart Samwel (bart-samwel) wrote : Re: [Bug 59695] Re: default value in power.sh potentially kills laptop disks

I didn't see atime mentioned on the wiki page. Logging in fails for me
right now (takes forever), so perhaps somebody else could add this info:

If you're looking for something that definitely does cause disk activity
every 30 seconds, it's atime updates. When enabled (which they are by
default), access times are updated for all file system _reads_ (even
from the file system cache), and they are flushed very soon after (30
seconds AFAIK).

If the problem really is that something is accessing the disk very
often, atime is at least one of the most likely culprits. Mounting all
filesystems noatime (or at least relatime) could make a big difference.

Brian Visel wrote:
> I'm 99% sure that the problem lies not (so much) in the aggressive APM,
> but in the combination of the aggressive APM and some spurious constant
> disk activity. If the disk activity weren't there, it wouldn't be so
> much of an issue, and if the APM weren't so aggressive, it wouldn't be
> so much of an issue. I'll notate this on the wiki.

Revision history for this message
Christian Vogler (christian-vogler) wrote : Re: default value in power.sh potentially kills laptop disks

I have noatime enabled for all mounted filesystems, and it does not make the slightest difference for the load cycle count. So, while I agree that the disk activity should be tracked down, atime does not look to be the (only) culprit.

Revision history for this message
zdzichu (zdzichu-gmail) wrote :

Some data:
Thinkpad z61t, TOSHIBA MK1032GSX, Firmware Revision: AS026E
Bought in September 2006 (it is 13 months old now), used daily with Feisty Beta, Feisty, Gutsy.

Load_Cycle_Count 90690
Power_On_Hours 3254 I estimate this is true.
Power_Cycle_Count 850

        Advanced power management level: unknown setting (0x0080)

Revision history for this message
yonkeltron (yonkeltron) wrote :

I can confirm this bug on my Thinkpad T60 purchased spring of 2007.

=== START OF INFORMATION SECTION ===
Model Family: Hitachi Travelstar 5K100 series
Device Model: HTS541080G9SA00
Serial Number: MPBDL0XNHV95ZG
Firmware Version: MB4IC65R
User Capacity: 80,026,361,856 bytes
Device is: In smartctl database [for details use: -P show]
ATA Version is: 7
ATA Standard is: ATA/ATAPI-7 T13 1532D revision 1
Local Time is: Tue Oct 30 11:28:13 2007 PDT
SMART support is: Available - device has SMART capability.
SMART support is: Enabled

193 Load_Cycle_Count 0x0012 080 080 000 Old_age Always - 00698
9 Power_On_Hours 0x0012 094 094 000 Old_age Always - 2840
 12 Power_Cycle_Count 0x0032 100 100 000 Old_age Always - 330

Revision history for this message
Alec Wright (alecjw) wrote :

225 Load_Cycle_Count 0x0012 097 097 000 Old_age Always - 33260
and thats in a few weeks
so I think thats confirmed in gutsy.
Please make this high priority, I don't want to have to get a new hard drive every year!

Revision history for this message
Guy Van Sanden (gvs) wrote :

guys, please read the follow up to that article. Ubuntu only changes this setting when laptop_mode is on, which it isn't by default.
If laptop mode is off, but it is cycling that often, then it is caused by the default setting in your BIOS

Revision history for this message
Brian Ealdwine (eode) wrote : Re: [Bug 59695] Re: default value in power.sh potentially kills laptop disks

But note also that with how often Ubuntu touches the disk, it will quite
simply never park the heads, even if it is inactive. Actually, the
aggressive APM isn't really the issue (although it will, obviously,
affect the live to some extent), it's more that Ubuntu touches the HD on
a regular basis, thus making any park pointless -- and when combined
with aggressive parking on the drive, this sends the park count through
the roof.

On Tue, 2007-10-30 at 20:51 +0000, Guy Van Sanden wrote:
> guys, please read the follow up to that article. Ubuntu only changes this setting when laptop_mode is on, which it isn't by default.
> If laptop mode is off, but it is cycling that often, then it is caused by the default setting in your BIOS
>

Matt Zimmerman (mdz)
description: updated
Revision history for this message
Kirils Solovjovs (linux-kirils) wrote : Re: default value in power.sh potentially kills laptop disks

Can NOT confirm this on my laptop.

product: HP Compaq nc6120 (PN936AV)
Device Model: FUJITSU MHV2080AH PL

  4 Start_Stop_Count 0x0032 099 099 000 Old_age Always - 2204
  5 Reallocated_Sector_Ct 0x0033 100 100 024 Pre-fail Always - 8589934592000
  7 Seek_Error_Rate 0x000f 100 091 047 Pre-fail Always - 2615
  9 Power_On_Seconds 0x0032 095 095 000 Old_age Always - 2735h+51m+58s
 12 Power_Cycle_Count 0x0032 100 100 000 Old_age Always - 1457
192 Power-Off_Retract_Count 0x0032 100 100 000 Old_age Always - 40
193 Load_Cycle_Count 0x0032 100 100 000 Old_age Always - 4311
195 Hardware_ECC_Recovered 0x001a 100 100 000 Old_age Always - 1075
196 Reallocated_Event_Count 0x0032 100 100 000 Old_age Always - 457900032
203 Run_Out_Cancel 0x0002 100 100 000 Old_age Always - 2628540432554

Revision history for this message
Johnathon (kirrus) wrote : Re: [Bug 59695] Re: default value in power.sh potentially kills laptop disks

----- "Neil Wilson" <email address hidden> wrote:
> *** This bug is a duplicate of bug 17216 ***
> https://bugs.launchpad.net/bugs/17216
>
> ** This bug has been marked a duplicate of bug 17216
> Hard drive spindown should be configurable
>
> --
> default value in power.sh potentially kills laptop disks
> https://bugs.launchpad.net/bugs/59695
> You received this bug notification because you are a direct
> subscriber
> of the bug.

Hi,

Why has this been made a dup of a Fix Committed bug, when the problem is clearly still valid.
IMHO, Ubuntu should override the insane hardware defaults, or find out why Ubuntu is writing to the disk every 30 seconds, to cause discs to spin down & then back up again.

Revision history for this message
LapTop006 (laptop006) wrote : Re: default value in power.sh potentially kills laptop disks

It's worth noting that even without laptop_mode some drives are just really bad at this. I had a Samsung 80GB drive that under any OS would park & spin down fairly aggressivly, but as soon as *ANY* power saving was enabled on the drive it would always spin down in 5 seconds (Unsurprisingly it died in less then 8 months, quick even for my average of ~ 1 year).

The only real potential solution is to work out a per model scale factor, but just upping the default might mask it enough to be effective.

Revision history for this message
Chris Moore (dooglus) wrote : Re: [Bug 59695] Re: default value in power.sh potentially kills laptop disks

> Why has this been made a dup of a Fix Committed bug, when the problem is clearly still valid.

It seems that there are some at Ubuntu who feel it is more important
to make the bug statistics look good than it is to actually fix
problems.

Several bugs I've raised have been closed rather than fixed.

(
attempting to post this comment using the website tells me:

Not Found

The requested URL /ubuntu/+source/acpi-support/+bug/59695/+addcomment
was not found on this server.
)

Revision history for this message
Johnathon (kirrus) wrote :

> (
> attempting to post this comment using the website tells me:
>
> Not Found
>
> The requested URL /ubuntu/+source/acpi-support/+bug/59695/+addcomment
> was not found on this server.
> )

Thats due to the slashdot-effect mitigation that they put in. (They re-directed the bug to a static html page.)

Revision history for this message
Bruce Cowan (bruce89-deactivatedaccount) wrote :

You lot only have yourselves to blame.

Revision history for this message
Johnathon (kirrus) wrote : Re: [Bug 59695] Re: High frequency of load/unload cycles on some hard disks may shorten lifetime

>
> You lot only have yourselves to blame.
>

Please keep in mind the Code of Conduct.
https://launchpad.net/codeofconduct/1.0.1

Kind Regards,

Johnathon

Revision history for this message
Bruce Cowan (bruce89-deactivatedaccount) wrote :

Never mind then.

I am fed up with the countless pointless comments on this bug, that's why it has had no attention.

Revision history for this message
Brian Ealdwine (eode) wrote : Re: [Bug 59695] Please.

This bug, and the many bugs that are duplicates of it, have many
comments that are confusing or inaccurate because people who are only
partially aware of how the computer works are trying to discover what is
causing a demonstrated problem. Also, people who have the access to
make changes in the Ubuntu operating system (I.e., the laptop team, etc)
haven't shown any clear leadership or care about the issue. Thus,
people who do not have the authority to make changes, and who are more
inexperienced with fixing this sort of problem are trying to fix the
problem themselves, because it is their only recourse. The end result
is a lot of hubbub, and little effective action.

I am requesting that the laptop team step in and take a helpful and
organizing role, and to do something about the issue, not because it is
their fault, but because no one else will or can, unless we change
operating systems.

Please.

This is an important issue.

It is causing information loss.

It is costing people money.

It is costing people pointless time, and pointless effort.

It is affecting the reputation of Ubuntu.

'''It is indicative of a failure in communications with Ubuntu that
needs addressing on a deeper level.''' Community requires sound
communication!

If I might suggest and be heard, it may be a good idea to select a few
power users who have the bug, then bring them into a semi-private
conversation of some sort, (maybe a private bug, if there is such a
thing), or simply a moderated bug of some sort in which comments from
those that are not directly pertinent to fixing the bug are deleted, and
a request not to become involved is sent. Then, with that limited group
of people, start seeking out the causes and sorting out solutions to the
problem. In the meantime, keep the public posted via this (the current,
incredibly busy and chaotic) bug. Acknowledged, this is not the only
way of going about it, and any methodology that *works* is ok. And of
course, a methodology that works and keeps people informed is
preferred.

Thank you for your time.

-Brian

Revision history for this message
technomaniac (technomaniac-tzp) wrote :

I get the following outputs
sudo smartctl --all /dev/sda | grep Load_Cycle_Count

193 Load_Cycle_Count 0x0032 057 057 000 Old_age Always - 86786

and

sudo smartctl --all /dev/sda | grep Power-Off_Retract_Count

192 Power-Off_Retract_Count 0x0032 100 100 000 Old_age Always - 831

I am using Gutsy.My laptop is a Sony Vaio and around 10 months old. Is it serious? Is there a problem. What to do?

Revision history for this message
Jonathan Musther (musther-deactivatedaccount) wrote :

Just thought I'd mention that this problem isn't only when running on battery, on my Toshiba A100 the load unload cycle count is increasing madly, 30-50 in just 5 minutes.

This really isn't good.

Revision history for this message
Peter Larson (dimbulb1024) wrote :

I found that when I remove Tracker Search Tool, my increase in count, which was hyper-ish, drastically reduced.

Revision history for this message
Brian Ealdwine (eode) wrote : Re: [Bug 59695] Re: High frequency of load/unload cycles on some hard disks may shorten lifetime

Thanks for the info. You might want to post it over on 17216, though.

-b

On Tue, 2007-11-06 at 04:43 +0000, dimbulb1024 wrote:
> *** This bug is a duplicate of bug 17216 ***
> https://bugs.launchpad.net/bugs/17216
>
> I found that when I remove Tracker Search Tool, my increase in count,
> which was hyper-ish, drastically reduced.
>

Revision history for this message
chrischan (nixlinder) wrote :

Hi everybody,

I have a VIA Epia board (EX10000EG) and a pretty new Western Digital 1 Terabyte WD10EACS drive. I am running Ubuntu 7.04, but I also tested with 7.10. No laptop mode, no fiddling with ACPI, just standard setup. Harddrive ACPI is disabled in BIOS. Nevertheless, can hear the drive load/unload every few seconds, my load cycle count is 5678 after 86 hours. The commonly mentioned fix "hdparm -B 254 /dev/hda" gives me

/dev/hda:
setting Advanced Power Management level to 0xFE (254)
HDIO_DRIVE_CMD failed: Input/output error

Can anyone comment on this latter issue or on the fact that I see this problem not on a laptop but on a desktop machine?

Best regards
Chrischan

Revision history for this message
pcfabix (dennisw76) wrote :

I have an IBM T23 Laptop with the latest Bios October 2006

Harddrive: Seagate Momentus ST92811A 20GB 5400 RPM ATA-6

My sudo smartctl -d ata -a /dev/sda|grep Hours and even on Battery I was going up at least a 100 per hour, I'm know at 85,578 Load Count

I tried this fix from http://blog.lynxworks.eu/?p=34
 /dev/sda {
  apm = 255
  spindown_time = 0
}

sudo update-rc.d hdparm defaults

That didn't fix it so I tired 244, no go..

I then tried a fix I saw on thinkwiki
sudo hdparm -B 254 /dev/sda

So far the count has finally stopped, hopefully this will stay, I really can't afford to replace the HD right now.

Revision history for this message
Brian Ealdwine (eode) wrote :

pcfabix:
Try rebooting and check if the settings stick around. In general,
Ubuntu_Demon is a great person to listen to on advice, and there are
several threads he has posted into about this particular problem:

http://ubuntuforums.org/showthread.php?t=591503
http://ubuntuforums.org/showthread.php?t=596602
http://ubuntuforums.org/showthread.php?t=589936
http://ubuntuforums.org/showthread.php?t=591564

Revision history for this message
Brian Ealdwine (eode) wrote :

duplicate 161239

Revision history for this message
tad.mcdearmont (tad-mcdearmont) wrote :

it seems as though my cycle count is quite high as well (HP Pavilion ze2308wm) however I have found a setting in the BIOS that may have solved it. I don't remember the commands to test though. Check you BIOS settings for a Battery power saver function of some sort. I turned mine off and have not noticed the clicking sound coming from my hard drive since doing so. I will need to get the commands to test and will need to figure it out. however it might be the cause...

Revision history for this message
ubuntu_demon (ubuntu-demon) wrote :
Download full text (3.7 KiB)

* (laptop) harddisk firmwares and (laptop) BIOSes might set too aggressive power management (operating system independent)
* The operating system and the applications running on it might cause too much unnecessary disk activity (multiple operating systems are affected. at least a couple of Linux distributions seem to have the same problem)
The result : is rapid parking/unparking cycles of the harddisk's head (a rapidly increasing Load_Cycle_Count).

IMHO this is the way Ubuntu should fix this :

IMHO this Load_Cycle_Count bug should be assigned critical priority.
IMHO Ubuntu should make fixing unnecessary disk activity bugs a high priority. We can all help finding unnecessary disk activity bugs.
IMHO Ubuntu should override too aggressive power management and make this also a high priority.
IMHO smartmontools should be installed on default. smartd should run on default with sane settings hooking into a notifier to notify users. At least some people who were affected might be warned in time to buy a new harddrive. Maybe this should be a Hardy goal ?

Laptop-mode with sane default settings can override too aggressive power management settings and can also prevent some unnecessary disk activity. Maybe Ubuntu should enable laptop-mode with sane default settings for laptops. What do you guys think ? What are sane default settings ?

Some suggestions for laptop-mode parameters :
http://www.suselinuxsupport.de/wikka.php?wakka=HowToSaveYourLaptopHD
http://mishameteo.blogspot.com/2007/10/ubuntu-default-acpi-settings-decreases.html
http://bbs.archlinux.org/viewtopic.php?pid=294594#p294594
http://forum.mandriva.com/viewtopic.php?p=393299&sid=46e5b548a1693fcf6f7e15316f904360#393299
https://launchpad.net/ubuntu/+source/acpi-support/+bug/59695/comments/63
http://www.nabble.com/-Cooker--Laptop-hard-drives-and-unnecessarily-high-Load_Cycle_Count-t4730198.html

Regarding smartd hooking into a notifier. I'm thinking of the following example situations when to warn a user :
* if the Load_Cycle_Count is increased with more than 22 cycles per hour (22 * 24 * 365 * 3 < 600.000) (to find people who are still affected)
* if smartctl assesses your harddrive as not healthy
* if more than X errors were found during the last self-test
* if Load_Cycle_Count's WORST is within Y of Load_Cycle_Count's THRESHOLD

I found the following wiki pages with similar ideas :
https://wiki.ubuntu.com/UbuntuDownUnder/BOFs/SMARTMonitoring
https://wiki.ubuntu.com/DiskMonitoring

Some bug reports about unnecessary disk activity. These bugs are possible contributors to the Load_Cycle_Count issue.

* the commit interval for the ext3 filesystem should be higher than 5 seconds for laptop users
https://bugs.launchpad.net/ubuntu/+source/util-linux/+bug/160448

* ext3 partitions should be mounted with noatime or relatime for laptop users
https://bugs.launchpad.net/ubuntu/+source/util-linux/+bug/160450

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

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

* thunderbird might cause unnecessary disk activity
https://bugs.launchpad.net/ubuntu/+sourc...

Read more...

Brian Ealdwine (eode)
description: updated
Revision history for this message
Brian Ealdwine (eode) wrote :

I updated the description to reflect current information.

description: updated
Revision history for this message
George (gapop) wrote :

I don't see any difference at all in the rate of increase of the load cycle counter between Feisty and XP Pro. It's about 24-25 units/hour for both. Dell laptop with Seagate hard disk. I used to have a Hitachi disk on the same computer and I remember the audible clicks were more frequent (about every 10-15 seconds), so I guess that one had a higher load cycle rate.

It would be great to hear from someone who actually knows whether this is a problem or it's normal. It is well known that different HD manufacturers implement SMART in different ways and that the numbers cannot always be compared, and that often only the manufacturer can read them properly. Some people here draw the line at 600,000, others report readings in the billions for their functioning hard disks.

Revision history for this message
Concolor (concolor22) wrote :

I own a Dell inspiron 1520 with a newly replaced Fujitsu MHY2160B 160gb HD. Upon typing in

sudo smartctl -A /dev/sda

I'm given a host of information [i]except 193 Load_Cycle_Count[/i].

Any clues why? Does my drive not support this? Using grep | 193 gives me a blank. Nothing.

Also, is there a way to include the fix 'hdparm -B 254' or '255' in the /etc/hdparm.conf file? I believe in automating anything I can.

Revision history for this message
ubuntu_demon (ubuntu-demon) wrote :

to Concolor :

Sometimes Load_Cycle_Count is listed under a different number instead of 193 that's why it's better to grep for Load_Cycle_Count.

Please don't use the bug tracker for support. Here's the support thread for this issue :
http://ubuntuforums.org/showthread.php?t=591503

Revision history for this message
Brian Ealdwine (eode) wrote :

On smartctl reporting numbers in the billions:
HW does not always report information the same way when queried. Some
HD's are reported in a different way than expected, but that hardware
which does so will also increase its Load_Cycle_Count not by one every
time, but by some exponent of two (generally speaking).

That aside, hardware that doesn't fit the problematic case to which we
are referring in no way invalidates that case.

> Some people here draw the line at 600,000, others report
> readings in the billions for their functioning hard disks.

Revision history for this message
gagarine (gagarine) wrote :

The workaround posted at comment https://bugs.launchpad.net/ubuntu/+source/acpi-support/+bug/59695/comments/14 work fine on a lot of configuration. Why don't commit this in urgency before a better solution?

Revision history for this message
ubuntu_demon (ubuntu-demon) wrote :

to gagarine :
* because currently the reasoning goes that manufacturers should set appropriate settings (because they should know what their hardware is capable of)
* because applying an apm of 254 might cause the harddrive's temperature too increase too much for some harddisks
* because it isn't trivial to find the right power management settings. An apm of 192 is different for each harddisk.
* because it is not only power management which causes this issue. It's a combination of disk access and power management.
* because this workaround also uses 254 also when running on battery. When running on battery the disk you don't want to disable parking of the head to protect the harddisk. I based the ugly fix I recommend *only* for heavily affected users who understand what they are doing on this workaround and other comments : http://ubuntuforums.org/showpost.php?p=3675960

I think this bug should get a higher priority. IMHO wishlist is too low. Some suggestions about what might be done :
https://bugs.launchpad.net/ubuntu/+source/acpi-support/+bug/59695/comments/185

Revision history for this message
ubuntu_demon (ubuntu-demon) wrote :

Currently this bug is filed against acpi-support. acpi-support might be replaced by pm-utils in the future.

How does https://blueprints.launchpad.net/ubuntu/+spec/pm-utils-integration relate to this bug ?

Revision history for this message
Shaun Senecal (senecaso) wrote :

Has anyone tried running hdparm from Cygwin on Windows to determine what MS is setting the values to? Could this be as simple as getting the values from Windows for your laptop/hard drive and then using those values in a startup script under Linux?

I dont have my laptop yet, so I cant try it myself. However, I'm following this issue closely as I want to make sure I set it up correctly (under Linux) when it finally comes in :)

Revision history for this message
Rino Mardo (rino-mardo) wrote :

Shouldn't it be read as "temporarily" as that value 255 disables APM for the hard disk making it run hotter.

Revision history for this message
ubuntu_demon (ubuntu-demon) wrote :

to Rino Mardo :
The value for disabling apm is 254.

Revision history for this message
Rino Mardo (rino-mardo) wrote :

254 or 255 both disabled my APM.

anyway, the best i found, IMHO, is to edit /etc/laptop-mode/laptop-mode.conf and change CONTROL_HD_POWERMGMT=0 value to 1, then reboot.

my Load_Cycle_Count and Temperature_Celsius remained to a reasonably low values. no frequent hard disk clicking.

Revision history for this message
Lea Wiemann (lewiemann) wrote :

On my hard disk (Toshiba MK3006GAL), 255 did not give much improvement, but 254 solved the problem. I have not tested CONTROL_HD_POWERMGMT. The temperature went up from about 44 to 47 degrees celcius (no controlled testing environment though), which is still well within range. Considering that my laptop is entirely passively cooled (no fans), I suspect that temperature is not going to be a major issue here, compared to the load cycles.

Revision history for this message
Lea Wiemann (lewiemann) wrote :

And since I've had hard disks throwing errors within short time spans, quite possibly because of the high load cycle count, I'll be the 50th person to request that the importance of this issue be increased—"Wishlist" is definitely too low.

Revision history for this message
gagarine (gagarine) wrote :

What don't put this issue is critical?

For me is a really good reason to switch on Debian (or other REAL open dist). All dist has perhaps this issue BUT i don't think they stay with a "wishlist" importance after all this comments....

What the problem with Ubuntu team?

I lose my hard disc on a 7 month old t60p with a very high load cycle count:
  9 Power_On_Hours 0x0032 098 098 000 Old_age Always - 1799
193 Load_Cycle_Count 0x0032 001 001 000 Old_age Always - 820538

hazard?

Revision history for this message
Mathieu Marquer (slasher-fun) wrote :

gagarine, please don't make this kind of useless comments. Ubuntu team is working on this problem. Please only add comments if you can HELP fixing this issue, not if you just want to say things that don't help.
Thanks.

Revision history for this message
SirLancelot (lukaszgraczyk) wrote :

Hi

I have only one question. Should I stop Load_Cycle_Count using solution:

File:

99-hdd-spin-fix.sh

With:

#!/bin/sh
hdparm -B 255 /dev/sda
hdparm -S0 /dev/sda

Into:

/etc/acpi/suspend.d/
/etc/acpi/resume.d/
/etc/acpi/start.d/

This solution stopped my HDD Load_Cycle_Count number at 128317 after 1 year using my laptop.

OR

I should do nothing and wait for official solution from Canonical?

I don't know what is better for my HDD. Stop the Load_Cycle_Count or leave it like it worked earlier?

Could someone give me an answear? I don't want to make something wrong with my HDD.

What is better? Stopped Load_Cycle_Count or HDD with high temperature?

Thank's for help!

Revision history for this message
Ignas Mikalajūnas (ignas) wrote :

Don't know about Load_Cycle_Count, but Power-Off_Retract_Count seems to be a bug in smartctl OR the firmware that gives this number. On my Ubuntu thinkpad it is:

192 Power-Off_Retract_Count 0x0032 100 100 000 Old_age Always - 548864062

with

9 Power_On_Hours 0x0012 079 079 000 Old_age Always - 9588

that would mean 14 retracts per second and if that was happening i assume i would feel the difference. Oh and if it's 7 million - you have at least 541,864,062 cycles to go ;)

193 Load_Cycle_Count 0x0012 087 087 000 Old_age Always - 135209

but still, I haven't noticed anything unusual. And since i have disabled beagle and the likes i don't seem to be getting sounds from hard drive when it is not working.

model of the hard drive is HTS541040G9AT00

Revision history for this message
changlinn (morganstorey) wrote :

This is a pretty major issue, mainly Hitachi drives, I have checked about ten ubuntu laptops in the last week, three that had hitachi are over the half million load unloads, the youngest of these was 6months old. I think this should be rolled into an update and pushed out to all supported versions.

Revision history for this message
Nizar Kerkeni (nizarus) wrote :

this bug is more than 3 months old and affecting a lot of ubuntu users and still in which list !!! Is the Ubuntu Laptop Team still alive or what

Revision history for this message
Mathieu Marquer (slasher-fun) wrote :

Nizar, please don't post this kind of useless comment. If you can help, please do so. If not, please just wait, Ubuntu Laptop Team is working on this issue. Nobody forces you to use Ubuntu, and you are free to change your operating system. I remind you that this bug also affects other distributions than Ubuntu.

Regards,

Revision history for this message
Brian Ealdwine (eode) wrote :

It would, however, be nice to have some regular updates from the laptop
team to let us know how things are coming along. We really need some
communication here.

Revision history for this message
Bayar (bayar-mehdi) wrote : there is devices without SMART support?

hello,
my laptop : IBM thinkpad R50e
Ubuntu : Feisty 7.04

i added this comment perhaps it can be useful !
--------------------------------------------------------------

smartctl --all /dev/sda

-->
smartctl version 5.36 [i686-pc-linux-gnu] Copyright (C) 2002-6 Bruce Allen
Home page is http://smartmontools.sourceforge.net/

Device: ATA HTS541060G9AT00 Version: MB3I
Serial number: *****
Device type: disk
Local Time is: Tue Nov 20 00:08:30 2007 CET
Device does not support SMART

Error Counter logging not supported

[GLTSD (Global Logging Target Save Disable) set. Enable Save with '-S on']
Device does not support Self Test logging

Revision history for this message
Daniel Bermudez G. (nergar) wrote : Re: [Bug 59695] Re: High frequency of load/unload cycles on some hard disks may shorten lifetime

That's not the point...

On Mon, 2007-11-19 at 20:51 +0000, slasher-fun wrote:
> Nizar, please don't post this kind of useless comment. If you can help,
> please do so. If not, please just wait, Ubuntu Laptop Team is working on
> this issue. Nobody forces you to use Ubuntu, and you are free to change
> your operating system. I remind you that this bug also affects other
> distributions than Ubuntu.
>
> Regards,
>

the point is; we users want updates on what is happening with this
issue, this is taking a lot of time without a real fix and we are
talking about affecting hardware. So even if I change OS right now, the
damage is done.

Revision history for this message
Ralf Nieuwenhuijsen (ralf-nieuwenhuijsen) wrote : Re: [Bug 59695] Re: High frequency of load/unload cycles on some hard disks may shorten lifetime

Well, you can blame people for getting a little annoyed.
I've seen four types of responses on this bug:
  - complaining about the bug: not usefull
  - people playing the blame-game and dismissing importance and
reponsibility: you have no clue how much you are hurting Ubuntu's
reputation. See entries such as: "ubuntu' s NOT destoying
hard-drives", etc.
  - people trying to solve the issue (a.k.a heroes)

My two cents:
  - stop complaining about this bug, its not constructive
  - bug-watch admin should _acknowledge_ importance of the bug . Just
by turning priority to critical you are saying "we care". You are not
saying "its our fault". Half of the comments here are about the
priority and the we-dont-care-message associated with wishlist
priority.
   - leave the blame-game discussion until the issue until fix-released

_Afterwards_, a inquiry on why the community interaction has failed
could be wise.

Revision history for this message
In , Andrey (andrey-redhat-bugs) wrote :

TOSHIBA Satellite L30-113 notebook.
Intel Celeron 430M, ATI Radeon Xpress 200M.
Fedora 8.

== Increasing Load_Cycle_Count ==

[root@fedora ~]# smartctrl --all /dev/sda
[...]
Model Family: Hitachi Travelstar 5K100 series
Device Model: HTS541060G9SA00
Serial Number: MPBCPAXMGMV6PM
Firmware Version: MB3OC60R
User Capacity: 60,011,642,880 bytes
Device is: In smartctl database [for details use: -P show]
ATA Version is: 7
ATA Standard is: ATA/ATAPI-7 T13 1532D revision 1
Local Time is: Tue Nov 20 18:03:50 2007 VLAT
[...]

[root@fedora ~]# smartctl --all /dev/sda|grep -i count
  4 Start_Stop_Count 0x0012 100 100 000 Old_age Always
- 432
 10 Spin_Retry_Count 0x0013 100 100 060 Pre-fail Always
- 0
 12 Power_Cycle_Count 0x0032 100 100 000 Old_age Always
- 432
192 Power-Off_Retract_Count 0x0032 099 099 000 Old_age Always
- 211
193 Load_Cycle_Count 0x0012 090 090 000 Old_age Always
- 103707
196 Reallocated_Event_Count 0x0032 100 100 000 Old_age Always
- 1
199 UDMA_CRC_Error_Count 0x000a 200 253 000 Old_age Always
- 0

but a hour ago Load_Cycle_Count was: 103698

== ReiserFS or ...? ==

Day ago I leave my notebook on 30 minutes, and when I came back I was heard
that my HDD was buzzing!
[noisy like the sound of a bee; doing something hard]
I tried to do something, but Fedora don't respond.. even if I press Ctrl+Alt+F2
or Ctrl+Alt+Del..
I wait about 10 minutes..
I was forced to press and hold PowerOff button for 5 seconds for hard-shutdown..
When I turn on my laptop, I found something strange in /var/log/messages file:

Nov 19 22:09:23 fedora yum: Installed: unrar - 3.7.8-1.lvn8.i386
Nov 19 22:43:34 fedora kernel: ReiserFS: sda6: warning: vs-8115: get_num_ver:
not directory or indirect item
Nov 19 22:43:34 fedora kernel: ReiserFS: sda6: warning: vs-8115: get_num_ver:
not directory or indirect item

And before this Load_Cycle_Cont was about 96###, and after - 102### ...

Revision history for this message
In , Andrey (andrey-redhat-bugs) wrote :

I think I found solution to stop increasing Load_Cycle_Count.

]# hdparm -I /dev/sda|grep Advan
        Advanced power management level: 128 (0x80)
           * Advanced Power Management feature set

The solution:
]# hdparm -B 255 /dev/sda

/dev/sda:
 setting Advanced Power Management level to disabled

]# hdparm -I /dev/sda|grep Advan
        Advanced power management level: 254 (0xfe)
                Advanced Power Management feature set

Now Load_Cycle_Count stopped increasing!

Revision history for this message
In , Phil (phil-redhat-bugs) wrote :

Reassigning this bug to the kernel component as it's a bug in that component.

Read ya, Phil

Revision history for this message
Chris Jones (cmsj) wrote :

This issue has been extensively covered in the press recently and, as should be blindingly obvious by now, is, by and large, nonsense.

First of all, let me make this absolutely clear - you should pay ZERO attention to the number reported by smartctl for Load_Cycle_Count. It is probably not a raw counter showing the number of times your drive heads have unparked. If you don't believe me, look at this output from my Thinkpad X40:

193 Load_Cycle_Count 0x0032 070 070 000 Old_age Always - 3037783573354

That number is over 3 *trillion*, which, for a 14 month old laptop is physically impossible, it would have to be unparking the heads 80,000 times *a second*. Again, this is physically impossible.

What you should be paying attention to are the THRESH, VALUE and WORST columns. This is an Old_age SMART value, so the VALUE starts at 100 and counts down to 0. When it crosses THRESH it means your drive manufacturer believes your drive has reached the end of its probable lifespan.

So, in my above example, the THRESH, VALUE and WORST columns are 70, 70 and 0 respectively. In this case VALUE and WORST will always be the same because it's simply counting down over time and in this case, I have used about 30% of the expected lifespan of my drive, which, at 14 months and it being a rubbishy 1.8" laptop drive, seems entirely reasonable.

My value will be lower than a stock install would because I've had laptop_mode enabled for at least a year, so the heads are unparking quite aggressively.

So, to be absolutely, entirely clear about this, Ubuntu is not killing my hard disk, no matter what Slashdot and misinformed blog posts claim.

To everyone who has commented on this bug with wild claims about how much their Load_Cycle_Count value is increasing, go back to smartctl's output and check the VALUE and THRESH columns and I am entirely confident you will find that your drive is well within expected lifespan.

The reason is because the RAW_VALUE column is entirely manufacturer specific. A few drives will actually report a counter of the number of times they've unparked the heads, but many/most report something that we have no idea about the meaning of. It's not a meaningful number. SMART is not designed to report meaningful numbers like that, it is designed to provide an indication of health that is interpreted by the firmware on the drive itself, this is what the VALUE, THRESH and WORST columns are for. Use them.

Revision history for this message
Mathieu Marquer (slasher-fun) wrote :

193 Load_Cycle_Count 0x0022 075 075 000 Old_age Always - 50485
I've bought the computer at the end of August 2007, and started using hdparam -B192 since the end of october. So we can consider that in two months, I've used 25% of the timelife for this parameter, meaning that if I would not have noticed that problem, this value would have arrived at 0 only after 8 months...

Revision history for this message
In , Chuck (chuck-redhat-bugs) wrote :

That value is set by the system BIOS at power-on; we never change it. (Some
other distributions do, but not Fedora.)

Revision history for this message
ubuntu_demon (ubuntu-demon) wrote :

to Chris Jones :

Because you don't suffer from this issue doesn't mean nobody suffers from it.

Some examples of people suffering from this problem :

http://ubuntuforums.org/showpost.php?p=3677732&postcount=174
http://ubuntuforums.org/showpost.php?p=3677803&postcount=175
193 Load_Cycle_Count 0x0032 001 001 000 Old_age Always - 713621
age : bought in August

http://ubuntuforums.org/showpost.php?p=3676465&postcount=161
193 Load_Cycle_Count 0x0032 001 001 000 Old_age Always - 337032
age : bought in July

Revision history for this message
Brian Ealdwine (eode) wrote : Re: [Bug 59695] Re: High frequency of load/unload cycles on some hard disks may shorten lifetime
Download full text (4.2 KiB)

Chris,

You're right that people should, by and large, be going off of "thresh,
value, and worst". And, no, it doesn't hurt to look at the count, if
the count on your particular system is accurate -- in fact, it can be
quite helpful when checking to see if your system has stopped
parking/unparking unnecessarily, or in counting just how often your
system *is* undergoing a load/unload cycle. However, the raw value (the
count at the end of the list) is not nearly the reliable life-expectancy
counter that thresh/value are (assuming you know the starting/high value
of "value/worst").

> - 3037783573354
>
> That number is over 3 *trillion*, which, for a 14 month old laptop is
> physically impossible, it would have to be unparking the heads 80,000
> times *a second*. Again, this is physically impossible.

Obviously, yours is one case that fits the (documented) circumstance
where the value is not printed out accurately for your hard disk. There
are methods to reformat this output so that it displays accurately. You
have probably read up on this, but mistook the meaning. If you haven't
read up on it, you can, at:
http://smartmontools.sourceforge.net/

My counter goes up by one every time the HD parks and unparks. My
counter is at 171,983. My drive is rated for 600,000 parks. My thresh
is zero, and my value/worst have a starting value of 200, and are at
143. The ratios in relation to each other are accurate.

I have not changed anything regarding laptop mode on this system. By
default, laptop mode is not on in Ubuntu. Likewise, laptop mode is not
on on my system, and never has been. Laptop mode is not this issue.
This has been established already. I myself thought Ubuntu came with
Laptop mode enabled, but have learned differently (and that it wasn't
enabled on my system, either) along the way.

Over a quarter of my HD life is gone, and I've had this laptop for about
half a year. That puts the usable lifetime just under two years. Last
I checked, hard disks did not have a life expectancy of less than 2
years. In fact, my Western Digital Scorpio has a MFG warranty of 3
years. I doubt they expect it to die within that time. 5 years gives
them a nice margin of error, but four years would even do it for them, I
imagine.

> So, to be absolutely, entirely clear about this, Ubuntu is not killing
> my hard disk, no matter what Slashdot and misinformed blog posts claim.

To be absolutely clear about this, I would appreciate it if you had a
greater understanding of the situation before claiming that there is no
problem. There very definitely is a problem, the problem has existed
for a very long time, and it does indeed cause hard drives to break. I
have been with Ubuntu for a long time, and I intend to stay with Ubuntu.
But this problem must be acknowledged and dealt with, and
misinformation, albeit with good intent, does not help that. A review
of the posted information could have provided you with enough
information to know that there are valid cases here.

> To everyone who has commented on this bug with wild claims about how
> much their Load_Cycle_Count value is increasing, go back to smartctl's
> output and check the VALUE and...

Read more...

Revision history for this message
Lea Wiemann (lewiemann) wrote : Re: [Bug 59695] Re: High frequency of load/unload cycles on some hard disks may shorten lifetime

Hey Chris,

I doubt you are correct about that. These are my values:

> ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_FAILED RAW_VALUE
> 193 Load_Cycle_Count 0x0032 072 072 000 Old_age Always - 289087

I assume VALUE is going down linearly as RAW_VALUE increases up to 1M,
since 289087 / (1 - 0.72) = 1M. Normally, RAW_VALUE increases by two
counts every minute. That means that at 12h usage per day, it will
increase by 12*60*365*2=525600 a year, placing the drive's life span at
2 years; less, if I use it more than 12h per day. Also, I'd expect that
the drive's reliability will go down quite a bit before VALUE actually
reaches 0.

If I run hdparm -B 254, Load_Cycle_Count increases almost not at all, so
I may have some hope that my drive will survive longer -- esp. since
none of the other VALUE's are as low as 72, the next lowest one being
Power_On_Hours [Old_Age] with 88.

So, for certain usage patterns (drive spinning continuously for long
hours), the load/unload cycles do seem to be problem, at least on my
laptop -- or would you disagree?

(I'm using Debian by the way, but from the other reports I've seen I
believe I'm having the same problem that some Ubuntu users have.)

-- Lea

Revision history for this message
George (gapop) wrote :

Chris,

It was bad enough obsessing about one mysterious number, but now your remarks regarding VALUE and THRESH really got me worried. Here's my reading:

193 Load_Cycle_Count 0x0032 026 026 000 Old_age Always - 149312

I've been using this Seagate hard disk for less than a year, and VALUE has already dropped to 26. My records show that it's dropped 2 units since Nov. 1. Are you sure those numbers are any more significant than the raw value (which I'm not particularly worried about)? Other "old age" readings look reasonable, for instance:

  4 Start_Stop_Count 0x0032 100 100 020 Old_age Always - 487
  9 Power_On_Hours 0x0032 096 096 000 Old_age Always - 3917
 12 Power_Cycle_Count 0x0032 100 100 020 Old_age Always - 494

and a different one looks like a terminal diagnosis:

189 Unknown_Attribute 0x003a 001 001 000 Old_age Always - 256

Revision history for this message
Bart Samwel (bart-samwel) wrote :

Lea Wiemann wrote:
> (I'm using Debian by the way, but from the other reports I've seen I
> believe I'm having the same problem that some Ubuntu users have.)

FYI: In Debian the hdparm -B 254 workaround has been included in
acpi-support (version 0.103-4). This'll at least keep the hard drives
alive until a better solution comes along.

Cheers,
Bart

Revision history for this message
Chris Jones (cmsj) wrote :

Brian: Thanks for reminding me that the Old_age values don't always necessarily start at 100.

I apologise if anyone thinks I am being harsh, but I see a lot of hair pulling about how drives are going to die in 6 months, with numbers that are very hard to interpret (something I am clearly guilty of, because there were some mistakes in my comment).

It's also interesting to see VALUEs of 001 in ubuntu_demon's comment - I find it extremely hard to believe that this is actually true. It's yet more evidence of vendor specific SMART behaviour, which puts even more doubt on the available data, especially since those posts don't appear to be shortly followed by VALUEs of 000 with a FAILING_NOW tag.

I suggest that anyone who is genuinely worried about their disk confirm the output of smartctl by running a tool from their hard disk's vendor (the smartmontools FAQ lists http://www.benchmarkhq.ru/english.html?/be_hdd2.html as a good source thereof, and has information about ways to run them, since they are mostly MS-DOS tools).

Revision history for this message
ubuntu_demon (ubuntu-demon) wrote :

Bart Samwel thanks for notifying us. Do you think acpi-support should be modified to use "hdparm -B 254" while on AC and "hdparm -B 128" while on battery (including booting from battery)? While on battery you generally want to save power and protect your disk from bumps by parking as soon as possible.

Reducing unnecessary disk activity will prevent some unnecessary unparking while on "hdparm -B 128". Here's some possible disk activity bugs :

* the commit interval for the ext3 filesystem should be higher than 5 seconds for laptop users
https://bugs.launchpad.net/ubuntu/+source/util-linux/+bug/160448

* ext3 partitions should be mounted with noatime or relatime for laptop users
https://bugs.launchpad.net/ubuntu/+source/util-linux/+bug/160450

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

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

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

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

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

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

Revision history for this message
ubuntu_demon (ubuntu-demon) wrote :

Bart Samwel do you think acpi-support should set apm 128 while on battery or that laptop-mode should be enabled by default ? Do you think the default settings of laptop-mode in Ubuntu are sane ?

Revision history for this message
zanonmark (info-marcozanon) wrote :

confirming the problem EVEN when on AC power,

(also confirming that you can circumnavigate the problem by setting "hdparm -B 255 /dev/sda" and entering the correct values in /etc/hdparm.conf),

Dell Vostro 1000 (less than 2 weeks old, had about 1450 Load_Cycle_Counts on 13 hours of activity)
HD is a 120Gb Seagate ST9120822AS

MZ

Revision history for this message
Bart Samwel (bart-samwel) wrote :

ubuntu_demon wrote:
> Bart Samwel thanks for notifying us. Do you think acpi-support should be
> modified to use "hdparm -B 254" while on AC and "hdparm -B 128" while on
> battery (including booting from battery)? While on battery you generally
> want to save power and protect your disk from bumps by parking as soon
> as possible.

In my opinion, the only time when it is really safe and useful for the
HD to do -B with less than 254, is when laptop mode is enabled. In
Debian I wrote it so that control is left to laptop-mode-tools when
laptop mode is enabled and configured, so in those cases the user can
configure it differently. In all other cases we cannot be sure that it
is safe, so we apply -B 254.

--Bart

Revision history for this message
ubuntu_demon (ubuntu-demon) wrote :

Maybe the best Ubuntu can do for now is :
* Ubuntu should probably sync the acpi-support fix from Debian (at least for now)
* let's all report unnecessary disk activity bugs (to improve Hardy)
* maybe Ubuntu Hardy should enable laptop-mode by default while running on battery with sane defaults

Revision history for this message
Bart Samwel (bart-samwel) wrote :

ubuntu_demon wrote:
> * maybe Ubuntu Hardy should enable laptop-mode by default while running on battery with sane defaults

Not this one. It was disabled for a good reason -- system hangs. Nobody
ever found the real reason, but this is a very real problem. :-/

Revision history for this message
Bart Samwel (bart-samwel) wrote :

ubuntu_demon wrote:
> Bart Samwel do you think acpi-support should set apm 128 while on
> battery or that laptop-mode should be enabled by default ? Do you think
> the default settings of laptop-mode in Ubuntu are sane ?

Yes, the default settings are sane. Disabling it by default is necessary
because of unexplained system hangs on some laptops. The only thing that
should change in that area is that the default HD powermgmt settings in
the laptop-mode.conf should be changed to 254 instead of 255, but
that'll happen automatically the next time they sync up with Debian. And
any power management setting <254 should be set only when laptop mode is
enabled -- but even that is not usually necessary since laptop mode
tools sets the spindown timeout (hdparm -S) instead.

Revision history for this message
ubuntu_demon (ubuntu-demon) wrote :

to Chris Jones :

I do encourage people to use the tools specific for their harddrive to test their harddrive if the information they supply regarding their Load_Cycle_Count looks bad. (the ultimate boot cd-rom contains most of these tools)

If I would use apm 128 on my new drive the Load_Cycle_Count increases by increments of one (I have tested this before) but very fast.

193 Load_Cycle_Count 0x0032 200 200 000 Old_age Always - 1335 | Wed Nov 21 13:40:02 CET 2007
193 Load_Cycle_Count 0x0032 200 200 000 Old_age Always - 1381 | Wed Nov 21 14:00:01 CET 2007
193 Load_Cycle_Count 0x0032 200 200 000 Old_age Always - 1446 | Wed Nov 21 14:20:01 CET 2007

If it would continue to rise this fast for 11 hours a day I would reach 600.000 Load_Cycles within a year.

Another example from http://ubuntudemon.wordpress.com/2007/10/28/laptop-hardrive-killer-bug-how-to-discover-whether-you-are-affected/#comment-31508

Sander's Load_Cycle_Count also seems to increment by one which means his raw value is probably correct. He has reached almost 1.9 million Load_Cycles in two years of usage. (he should have grepped for Load_Cycle_Count instead of 193 but that's besides the point)

[quote=Sander]
I have a two-year old powerbook G4, with a Seagate Momentus 5400.2 series 100GB. They also report a minimal lifetime of 600,000 cycles (http://www.seagate.com/docs/pdf/datasheet/disc/ds_momentus5400.pdf)

Mine is however already at 1,900,000! (more than three times as much), and still increasing rapidly. I use Ubuntu Gutsy at the moment.

I ran the following script:
while (true); do smartctl -a /dev/hda | grep 193 >> hw.txt; sleep 60; done

And the output was:
193 Load_Cycle_Count 0×0032 001 001 000 Old_age Always - 1897663
193 Load_Cycle_Count 0×0032 001 001 000 Old_age Always - 1897663
193 Load_Cycle_Count 0×0032 001 001 000 Old_age Always - 1897663
193 Load_Cycle_Count 0×0032 001 001 000 Old_age Always - 1897664
193 Load_Cycle_Count 0×0032 001 001 000 Old_age Always - 1897664
193 Load_Cycle_Count 0×0032 001 001 000 Old_age Always - 1897664
193 Load_Cycle_Count 0×0032 001 001 000 Old_age Always - 1897664
7 Seek_Error_Rate 0×000f 057 057 030 Pre-fail Always - 558423241934
193 Load_Cycle_Count 0×0032 001 001 000 Old_age Always - 1897670
193 Load_Cycle_Count 0×0032 001 001 000 Old_age Always - 1897671
193 Load_Cycle_Count 0×0032 001 001 000 Old_age Always - 1897674
193 Load_Cycle_Count 0×0032 001 001 000 Old_age Always - 1897677

So, once an error occured, and in 12 minutes it increased by 16! This does not look that good, doesn’t it?

Sander
[/quote]

Revision history for this message
Brian Ealdwine (eode) wrote : Re: [Bug 59695] Re: High frequency of load/unload cycles on some hard disks may shorten lifetime

Thank you so much, Debian!!!

Revision history for this message
ubuntu_demon (ubuntu-demon) wrote :

to Bart Samwel :

Thanks for being so helpful.

Did you fix Debian's acpi-support in such a way that it remembers apm 254 after suspend / hibernate ?
Did you consider the fact that some people might run into heat problems which also might affect the lifetime of their harddisk ?

Revision history for this message
Bart Samwel (bart-samwel) wrote : Re: [Bug 59695] Re: High frequency of load/unload cycles on some hard disks may shorten lifetime

ubuntu_demon wrote:
> to Bart Samwel :
>
> Thanks for being so helpful.
>
> Did you fix Debian's acpi-support in such a way that it remembers apm 254 after suspend / hibernate ?

Yes: the script 90-hdparm.sh is included in /etc/acpi/resume.d as well
as in /etc/acpi/start.d.

> Did you consider the fact that some people might run into heat problems which also might affect the lifetime of their harddisk ?

Yes. The heat problems that I've heard of are way less problematic than
the dead HDs, it's only a few degrees that we're talking about. They
can't possibly overheat, I mean, if a drive can overheat from just not
parking the heads, the enclosing system probably has way bigger thermal
issues. Death by updatedb. :-)

Revision history for this message
Brian Ealdwine (eode) wrote : Re: [Bug 59695] Re: High frequency of load/unload cycles on some hard disks may shorten lifetime

Chris:
> Thanks for reminding me that the Old_age values don't always
> necessarily start at 100.

Np..

> I apologise if anyone thinks I am being harsh, but I see a lot of hair
> pulling about how drives are going to die in 6 months, with numbers that
> are very hard to interpret (something I am clearly guilty of, because
> there were some mistakes in my comment).

Bah. I myself was rather grumpy and frustrated yesterday, so I should
be the one to apologize. I know this is a very cloudy issue with *many*
areas of potential misinterpretation -- I've posted things I've been
corrected about as well (and even argued the incorrect point ;-).

> It's also interesting to see VALUEs of 001 in ubuntu_demon's comment - I
> find it extremely hard to believe that this is actually true. It's yet
> more evidence of vendor specific SMART behaviour, which puts even more
> doubt on the available data, especially since those posts don't appear
> to be shortly followed by VALUEs of 000 with a FAILING_NOW tag.

I have to agree about the potential oddness of a value of 001, with the
reserve that it is still very possible that the numbers are correct.
This may be a case where load_cycle_count's raw value may be of use --
check the values, wait for the click, check the values, and see if it
has increased by one (in which case at least the raw value is probably
correct). This can then be compared against the spec sheet.

Of course, the preferred route would be, as you mentioned, download the
manufacturer's utility and run it.

Revision history for this message
Brian Ealdwine (eode) wrote : Re: [Bug 59695] Re: High frequency of load/unload cycles on some hard disks may shorten lifetime

Bart, thank you so much for the information!

We've been flying blind (I.e., had no communication) for a very long
time here.

-Brian

Revision history for this message
ubuntu_demon (ubuntu-demon) wrote :

to Bart Samwel :

Since it's currently impossible to recommend to turn laptop_mode on by default I'm currently recommending this to people who are heavily affected :
* use apm 128 while on battery (most head parks, best protection from bumps, lower power usage)
* use apm 254 while on AC (no protection from bumps,no head parks,best performance,increased heat)

The biggest reason to do so would be to protect the harddisk from bumps. Even if the laptop is used on battery everyday for four hours the Load_Cycle_Count would have to increase with 137 per hour to be able to reach 600.000 within three years of usage. Most people don't see their Load_Cycle_Count increase that fast (although some might). Most people don't use their laptop for four hours on battery each day. Those people who are afraid they will still reach the maximum Load_Count as specified by their manufacturer within three years of usage do need to tweak the "apm number while on battery".

This won't interfere with people who are using laptop-mode since laptop-mode doesn't touch apm but only spindown.

In my humble opinion you should consider doing something similar in acpi-support.

The full HOWTO for this ugly unofficial fix :
http://ubuntuforums.org/showpost.php?p=3675960&postcount=26

The interesting part of the HOWTO :

99-hdd-ugly-fix.sh :
========================
#/bin/bash
if on_ac_power = 1 ; then
hdparm -B 254 /dev/sda
else
# possibly on battery
hdparm -B 128 /dev/sda
fi
=========================

$sudo install 99-hdd-ugly-fix.sh /etc/acpi/suspend.d/
$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/

=========================

The first post of the support thread :
http://ubuntuforums.org/showpost.php?p=3733762&postcount=1

The support thread :
http://ubuntuforums.org/showthread.php?t=591503

Revision history for this message
Bart Samwel (bart-samwel) wrote : Re: [Bug 59695] Re: High frequency of load/unload cycles on some hard disks may shorten lifetime

ubuntu_demon wrote:
> Since it's currently impossible to recommend to turn laptop_mode on by default I'm currently recommending this to people who are heavily affected :
> * use apm 128 while on battery (most head parks, best protection from bumps, lower power usage)
> * use apm 254 while on AC (no protection from bumps,no head parks,best performance,increased heat)
>
> The biggest reason to do so would be to protect the harddisk from bumps.
> Even if the laptop is used on battery everyday for four hours the
> Load_Cycle_Count would have to increase with 137 per hour to be able to
> reach 600.000 within three years of usage. Most people don't see their
> Load_Cycle_Count increase that fast (although some might). Most people
> don't use their laptop for four hours on battery each day. Those people
> who are afraid they will still reach the maximum Load_Count as specified
> by their manufacturer within three years of usage do need to tweak the
> "apm number while on battery".

OK, I see how the math stacks up, and I agree. In that case the shock
protection probably outweighs the HD wear from the parking, even when
laptop mode is not enabled.

> This won't interfere with people who are using laptop-mode since laptop-
> mode doesn't touch apm but only spindown.

Not by default, but be aware that it _can_ be configured to configure
APM as well. That's why, in the acpi-support solution for Debian, I
added a check that laptop-mode.conf is configured to not touch APM. If
laptop-mode.conf is configured to do APM, acpi-support leaves APM alone
and lets laptop-mode-tools handle it.

> In my humble opinion you should consider doing something similar in
> acpi-support.

I'll definitely consider adding a switch to -B 128 on battery. However,
I'll have to do some calculation. I know of some laptops that have
9-hour battery lives, and on those laptops the math could be quite
different!

> $sudo install 99-hdd-ugly-fix.sh /etc/acpi/suspend.d/

(This one's not needed BTW.)

Revision history for this message
ubuntu_demon (ubuntu-demon) wrote :

to Bart Samwel :

Thanks for all your help in solving this problem. Having acpi-support setting some sane apm default while on battery and 254 while on AC would be a big help to solve this problem.

Possible problems with a default apm of 128 while on battery :
* some people might use their laptops *a lot* on battery. People who use their laptops for 9 hours a day and are seeing a Load_Cycle_Count increase of more 60 per hour will reach 600.000 Load_Cycles within three years of usage. The amount of people who would use their laptop for 9 hours each day are probably a very small minority. Using the laptop on battery for more than 9 hours a day increases the risk of bumps *a lot* which would make using apm 254 a sure harddrive killer. Their battery would probably be dead way before their harddrive dies. Some of these people might also prefer flash disks which don't have moving parts.
* Some users would use their laptop on battery for four hours each day. They would have a problem if their Load_Cycle_Count would increase with more than 136 per hour.
* If most people would run on battery for seven hours a week they would be able to handle 549 Load_Cycles per hour and still not reach 600.000 Load_Cycles within three years of usage.
* some people already have a really high Load_Cycle_Count because they have been using aggressive power management defaults set by their harddrive even while on AC. They would have to manually override this number of 128.

Possible problems with a default apm of 254 while on battery :
* no protection from bumps making it more likely for the harddrive to die from an accidental bump. The more you use your laptop on battery the higher the risk of death by bump.
* more power usage

Maybe some value between 128 and 254 works better for running on battery. The problem is that apm values between 128 and 254 are different for each harddrive and might even turn off head parking for some drives (as I understand it). If an apm of 253 would guarantee a "low amount of head parking but still do some headparking" that might be a more sane default for running on battery but as far as I know it doesn't (but I'm not an expert).

IMHO all of this makes very clear that reducing unnecessary disk activity is also very important.

Revision history for this message
ubuntu_demon (ubuntu-demon) wrote :

Certain desktop drives are also affected. Western Digital is using rapid parking as a selling point of it's green drives. They give three years of warranty but apparently they haven't tested these drives with a Linux desktop.

Western Digital's power saving desktop drives (WD Caviar GP) such as WD10EACS can handle 300.000 Load_Cycles
http://westerndigital.com/en/library/sata/2879-701229.pdf

Western Digital's power saving enterprise drives (WD RE2-GP) such as WD1000FYPS can handle 600.00 Load_Cycles
http://westerndigital.com/en/library/sata/2879-701236.pdf

chrischan has a WD10EACS and reported a load cycle count is 5678 after 86 hours. This means he is seeing 66 Load_Cycles per hour and his drive will reach it's specification (300.000) after 4544 hours of usage which is after 379 days
http://ubuntuforums.org/showpost.php?p=3719777&postcount=368

Revision history for this message
ubuntu_demon (ubuntu-demon) wrote :

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

ubuntu_demon wrote:
> Certain desktop drives are also affected. Western Digital is using rapid
> parking as a selling point of it's green drives. They give three years
> of warranty but apparently they haven't tested these drives with a Linux
> desktop.
>
> Western Digital's power saving desktop drives (WD Caviar GP) such as WD10EACS can handle 300.000 Load_Cycles
> http://westerndigital.com/en/library/sata/2879-701229.pdf
>
> Western Digital's power saving enterprise drives (WD RE2-GP) such as WD1000FYPS can handle 600.00 Load_Cycles
> http://westerndigital.com/en/library/sata/2879-701236.pdf
>
> chrischan has a WD10EACS and reported a load cycle count is 5678 after 86 hours. This means he is seeing 66 Load_Cycles per hour and his drive will reach it's specification (300.000) after 4544 hours of usage which is after 379 days
> http://ubuntuforums.org/showpost.php?p=3719777&postcount=368
>

WD gives three years of warranty on the power saving desktop drives and
five years of warranty on the power saving enterprise drives.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFHRupPadqpfxv/6LsRAg36AJ9zNZj4fSgWUMCtGdlaNhpON2pz2wCfc1Sg
NhX0Z/5XC5iFGSjxc1QEDyk=
=RoQV
-----END PGP SIGNATURE-----

Revision history for this message
Mark Thomas (mark-ubuntu-efaref) wrote :

@ Chris Jones:

ThinkPad X40 drives' raw value is a packed 48 bit number:

3037783573354 = 0x02C34A02C36A

0x02C34A = 181066
0x02C36A = 181098

One of these is your current load cycle count. The other is the load cycle count at some recent event (most recent power cycle or something, not sure exactly).

Revision history for this message
Jessica Litwin (jessica-penguinpost) wrote :

Here's my (dirty) fix.
http://j.wuffgirl.com/ubuntu_kills_discs.txt

I have not modified the drive's default APM setting in any way, and reinstalled Windows Vista Home Premium (the OS that came with the computer) to establish a baseline for comparison:

Using a port of hdparm for Windows I checked my drive's APM value:

ATA device, with non-removable media
        Model Number: Hitachi HTS541616J9SA00
        Serial Number: SB2401SJGTG1JB
        Firmware Revision: SB4OC7BP

--snip!--

Advanced power management level: 128 (0x80)

Using a Windows port of smartctl, over a period of exactly five minutes the Load_Cycle_Count went from 46190 to 46197 for a total of 7 load cycles. 7 load cycles every 5 minutes means 84 load cycles in an hour (unless my tryptophan-addled mind is incapable of basic math). A second five-minute test showed 6 load cycles, for a total of 72 in an hour (assuming again that six load cycles is constant).

Compared with my original findings (see URL above), editing /etc/laptop-mode/laptop-mode.conf and changing CONTROL_HD_POWERMGMT=0 to CONTROL_HD_POWERMGMT=1 showed a differece of 8 load cycles after 5 minutes, so again, assuming that the rate of load cycles remains constant, that's 96 in an hour.

As a footnote, disabling APM entirely *does* cause an increase in heat- smartctl displays the temperature min/max for my drive as 22/52C, but Hitachi's own temperature monitoring tool says to keep the drive between X/60C, where X is the lower value I can't remember at the moment. The temperature problem might not be as big an issue as some people are making it out to be.

I'm now going to reinstall Gutsy and start messing around with settings in laptop-mode.conf to see if I can get intervals between increments down.

Revision history for this message
Jessica Litwin (jessica-penguinpost) wrote :

> In /etc/laptop-mode-laptop-mode.conf:
> CONTROL_HD_IDLE_TIMEOUT=1
> LM_AC_HD_IDLE_TIMEOUT_SECONDS=300
> LM_BATT_HD_IDLE_TIMEOUT_SECONDS=300
> NOLM_HD_IDLE_TIMEOUT_SECONDS=7200
> CONTROL_HD_POWERMGMT=1
> BATT_HD_POWERMGMT=254
> LM_AC_HD_POWERMGMT=255
> NOLM_AC_HD_POWERMGMT=255
>
> In /etc/default/acpi-support:
> ENABLE_LAPTOP_MODE=true
> SPINDOWN_TIME=60

I can confirm that the above works to resolve the issue. It's also worthy to note that with my hard drive (Hitachi HTS541616J9SA00), a value of 200 for BATT_HD_POWERMGMT results in ~3 load cycles per hour, which is well under the reasonably defined limit of less than 15 per hour. It's then possible to lower the number incrementally if desired to find something closer to <15/hr, if more power management features are desired.

Revision history for this message
Alex Mayorga (alex-mayorga) wrote :

According to Debian upstream "Fixed in version acpi-support/0.103-2".
When would Ubuntu get this fixed, I have all my laptops running 7.10 and this is definitely a scary bit.

Revision history for this message
Mark Thomas (mark-ubuntu-efaref) wrote :

The Debian update is the workaround not the fix:

   * Set hdparm power management to 254 for all hard drives.

I'd be happier to see the known idle-writers fixed first, so we can start finding out what else causes the problem. I'm concerned that with a workaround in place this will get neglected and we'll end up just using more power.

Revision history for this message
Bart Samwel (bart-samwel) wrote :

Mark Thomas wrote:
> The Debian update is the workaround not the fix:
>
> * Set hdparm power management to 254 for all hard drives.
>
> I'd be happier to see the known idle-writers fixed first, so we can
> start finding out what else causes the problem. I'm concerned that with
> a workaround in place this will get neglected and we'll end up just
> using more power.

Please don't do this!

Here's the reason: it doesn't solve the problem for everybody. The set
of "known idle-writers" are just a subset of the set of "all
idle-writers". Fixing all *known* idle-writers (and then only in the
situations *known to be a problem*) will not fix *anything* for people
using just *any* program in the set "all idle-writers" minus "known
idle-writers". If you miss even *one* program in *one* possible uncommon
configuration or use case it might destroy somebody's hard drive.

Even if you fix *every* program delivered with Ubuntu, in *every*
possible configuration, I will be able to unwittingly write my own very
simple program that contains no bugs at all (it works perfectly), and it
will destroy my hard drive without me noticing it -- all it has to do is
write to disk every 30 seconds or so. Here is a perfectly harmless example:

#! /bin/sh
while true; do
   sleep 30
   (date ; uptime) >> load.log
done

This (untested) program logs my load averages (and uptime) every thirty
seconds. Using the default Ubuntu settings, it will kill the drive, even
if all known idle-writers are fixed.

Simply put: if an OS that allows unprivileged programs to *knowingly*
destroy hardware is not acceptable, then an OS that causes bug-free
programs to destroy hardware *without even knowing it* is not acceptable
either. So, either return an error to the user program
(-EIOTOOOFTENWHILEBEINGSPACEDABOUT30SECONDSAPARTASWELL :-) ) or fix the
problem: protect the hardware, regardless of what unprivileged programs
do. This is what the -B 254 fix does, and it does it well.

About your worry that the other programs may not get fixed: tough.
That's an internal organisational issue that users should not be
bothered with. If you're willing to fix an internal organisational issue
(not being able to push a set of fixes that the organisation deems
necessary) by putting all users' hard drives at risk,
then you're being totally reckless IMNSHO. Not to mention that it won't
actually help, because everybody who could be interested in changing
these programs (i.e., the Ubuntu contributors community) has already
applied the -B 254 workaround by now. In the end the end users will be
the only people without the workaround in place, and if you don't put it
in place for them, they will suffer.

Cheers,
Bart

Revision history for this message
ubuntu_demon (ubuntu-demon) wrote :

I reported a couple of 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/+source/laptop-mode-tools/+bug/172282

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

laptop-mode can't be enabled by default because using laptop-mode causes system hangs for some people
https://bugs.launchpad.net/ubuntu/+source/laptop-mode-tools/+bug/172293

Revision history for this message
kaltsoplyn (gkatsop) wrote :

I didn't have time to read everything here so I'm sorry if I state something already pointed out.

I followed the load_cycle_count discussions about a month ago and using smartctl, I found out I didn't have a problem. After about a week of monitoring the load cycling, the number increased by ~60-70 while in the vicinity of ~40000, or something like that. The numbers here are approximate but on the right order of magnitude. Note that APM was set to 128 and I run the laptop only on AC (battery is almost dead).

Today however, a month later, I noticed some characteristic hard drive parking clicks. Using smartctl I found out that my load cycle count has risen to about 92000 and it clicks at more than 10 times per minute. I immediately set APM to 254, which definitely works, but the issue remains:
My hdd was ok while set to APM 128 (and I have a _week_ of measurements to verify that), and a month later, out of the blue, the same hdd under the same settings is not ok any more.

(note: The only change in my system in the past month was installing the repository updates and some applications in the windows partition. Now in my understanding none of the newly installed/updated packages has anything to do with APM settings of the hdd! In conclusion, I feel this is one of these insanely random, Murphy's-law-abiding, software complexity issues, nobody is going to fully understand, let alone solve, any time soon :). That's what my inherent optimism dictates. But, hey, have fun trying :))

Revision history for this message
ubuntu_demon (ubuntu-demon) wrote :

another related bug (for those that wish to enable laptop-mode to decrease unnecessary diskactivity and prevent useless unparking of the head) :

laptop-mode should default to use relatime for ext3 partitions while on battery while keeping the option to use noatime while on battery
https://bugs.launchpad.net/ubuntu/+source/laptop-mode-tools/+bug/172301

Revision history for this message
Mark Thomas (mark-ubuntu-efaref) wrote :

Bart,

Disabling the APM feature of a drive can never be a fix. Parking the drives is a feature of the disk, and the The Load_Cycle_Count is supposed to go up, albeit slowly, during normal usage. The point of this bug is that the pathological worst case for load cycling is one access every 30 seconds or so, and Ubuntu is doing this by default.

It is not the place for the operating system to save the user from themselves. You are correct in that the user could write a program that was detrimental to their hardware, but that is their choice. Similary the user can write a program that writes constantly to one area of the disk - this will wear the disk out much faster than the expected life time of the disk, but there is nothing and should be nothing that any OS can do to stop that. We can't stop them from hitting their laptop with a hammer, either. Incidentally, it would be more likely to survive this if the hard drive heads were parked, and disabling APM will disable that.

Furthermore, it has been shown that disabling APM can cause some drives to over-heat, so they will be definitely damaged if you do that, and by putting extra load on the battery you will be reducing its operational lifespan, too.

Rolling out the workaround on every system, including those not currently affected, is a mistake. You will make the experience worse for some people (e.g. me. I have fixed all my idle-writers manually - my disk sleeps like a baby now), and you will make it possible for people to get lazy and ignore the problem, so it will never be fixed properly.

A better short-term workaround would be to monitor the disks, and bring up a pop-up bubble offering to disable APM if the LCC is increasing too fast. I believe someone already suggested this.

Revision history for this message
Chris Jones (cmsj) wrote :

I thoroughly agree with mark thomas - what is being proposed here will override the defaults set by hardware manufacturers and OEMs. Perhaps it is helpful for some people, but it's a blanket decision that will change the behaviour of a lot of systems - behaviour that was chosen by the people who know the hardware best (ie the people who made and/or integrated it).

I'm not sure if prompting the user is a wise idea because many people will not understand what it means, and since we can't predictably scale back the power management they'll just say "ooh that sounds bad" and click to turn the power management off, which may not be a good thing. We also don't know what "increasing too fast" means, since different drives have different levels of robustness. My drive would have prompted me after about half a second, unless we'd written up a list of every drive ever (and future drives for at least the next 6 months) and knew that mine counts with a 40bit packed number or whatever it was.

Revision history for this message
Fabien Lusseau (fabien-beosfrance) wrote :

Why not upgrading all ubuntu pcs to use this command automatically before the fix:

hdparm -B 254 /dev/sda

This bug is more than critical !!

with this bug too:

https://bugs.launchpad.net/ubuntu/+source/gnome-power-manager/+bug/135548

Ubuntu is very dangerous for Laptops !!!

All the pc will explode on the next version ! and it is an LTS !!!!

Revision history for this message
Andrea Corbellini (andrea.corbellini) wrote :

This bug is really critical. It has a severe impact on a large portion of users and affects an essential hardware component.
I mark it as it should.

Changed in acpi-support:
importance: Wishlist → Critical
Revision history for this message
Brian Ealdwine (eode) wrote : Re: [Bug 59695] Re: High frequency of load/unload cycles on some hard disks may shorten lifetime
Download full text (5.8 KiB)

-- Please pardon if this is a duplicate, I accidentally sent from the wrong account and I don't know how that's handled by launchpad.

> It is not the place for the operating system to save the user from
> themselves.

Whose opinion is that? I would argue that it is, indeed the operating
system's place to save the user from themselves. As a matter of fact,
if all these poor sots using email these days had to write their own
program to do it, they would likely fudge the data on the hardware in a
matter of moments. ..but the operating system makes sure that, at a
basic level, everything is operational, and things which can destroy the
system don't happen. You are, day in and day out, saved from your own
mistakes by others who have made them and fixed them. But in this case,
it's not even the user's mistake! If I install Ubuntu (default
install), turn my system on, and leave it -- doing nothing else -- the
system will break in less than two years. That is not normal. It is
not good. It is not user error. Even if it was user error, which it's
not, it can and should nevertheless be left to technically-oriented
users to mess up, but should work by default. A user cannot drag /usr
to the trashcan, for good reason.

> You are correct in that the user could write a program that
> was detrimental to their hardware, but that is their choice. Similary
> the user can write a program that writes constantly to one area of the
> disk - this will wear the disk out much faster than the expected life
> time of the disk, but there is nothing and should be nothing that any OS
> can do to stop that.

Perhaps. Definitely not prevent-altogether. However, an OS by default
should not have such behavior. In my opinion, an OS by default should
not even allow such behavior, but that is merely an opinion. But it is
not an opinion that an OS will prevent itself from performing its own
basic purpose if, by action or negligence, it fails to protect the
hardware from its own behavior.

> We can't stop them from hitting their laptop with
> a hammer, either. Incidentally, it would be more likely to survive this
> if the hard drive heads were parked, and disabling APM will disable
> that.

Yes, it would be more likely to survive being hit with a hammer if the
heads were parked. However, the heads only remain parked for a matter
of a few seconds, therefore, the protection is negligible anyway (in
this particular instance) due to the default activity of the OS.

> Furthermore, it has been shown that disabling APM can cause some drives
> to over-heat, so they will be definitely damaged if you do that, and by
> putting extra load on the battery you will be reducing its operational
> lifespan, too.

The power savings from parking the heads, in this case, are also
negligible -- again, because as soon as the heads are parked, they will
become unparked. If a disk is overheating through sustained operation,
that is *another* (and more drastic) design flaw, and one that is much
less common. In that case, the user will run into major problems anyway
-- for example, when watching a movie off of their hard disk, or
performing any activity which accesses the disk regu...

Read more...

Revision history for this message
Jay Strict (jay-strict) wrote :

Why not make the workaround available by the use of a configuration option?
The default would be, to apply the workaround. So each administrator could manually
disable it via "dpkg-reconfigure acpi-support", if she thinks it eats up battery power
or melts the harddrives.

This would help those users, who suffer from high load cycle counts.
(most laptop users, I think)
And it would satisfy those, who worry about high HD temperatures.
(seem to be many, too)

Revision history for this message
Bart Samwel (bart-samwel) wrote : Re: [Bug 59695] Re: High frequency of load/unload cycles on some hard disks may shorten lifetime
Download full text (3.7 KiB)

Mark,

Although I agree with some points you make, I want to question some
other assumptions.

Mark Thomas wrote:
> Disabling the APM feature of a drive can never be a fix. Parking the
> drives is a feature of the disk, and the The Load_Cycle_Count is
> supposed to go up, albeit slowly, during normal usage. The point of
> this bug is that the pathological worst case for load cycling is one
> access every 30 seconds or so, and Ubuntu is doing this by default.

I question the assumption that it needs to go up. I've had drives go
without load cycles for years, no problem. There are reasons for
parking: safety, and perhaps power usage (although that's fringe). IMHO
this means that it only strictly _needs_ to be on while on battery. As
ubuntu_demon pointed out earlier, leaving the APM setting at 128 while
on battery is probably mostly safe hard-drive-wear-wise, and has a
function. It is much harder to argue that APM needs to be enabled while
not on battery (i.e., not on the road).

> It is not the place for the operating system to save the user from
> themselves. You are correct in that the user could write a program that
> was detrimental to their hardware, but that is their choice.

I didn't mean to say that only programmers would have this problem, the
only reason I wanted to show a simple, seemingly harmless program was to
demonstrate that _any_ program that a user could install and run could
cause problems, without any clear sign that there would be anything
wrong with the situation.

What I mean to say is that *everybody* who runs *any* normal, bug-free
program on their computer now needs to be aware what the consequences
may be. Ubuntu is supposedly a distribution for people who don't have to
know these kinds of things. You're thinking of blaming my grandma if she
installs a third-party app, say, Skype (with some help from her
grandson) and then fails to check if it's an idle-writer? Be my guest!
But don't expect me to still consider installing Ubuntu on my grandma's
laptop. :-)

> We can't stop them from hitting their laptop with
> a hammer, either. Incidentally, it would be more likely to survive this
> if the hard drive heads were parked, and disabling APM will disable
> that.

Mostly useful in battery mode though. The next version of the workaround
in Debian's acpi-support package will set APM to 128 in battery mode and
to 254 on AC, to get the advantages of head parking (safety) on battery
while stopping the parking wear while plugged in.

> Furthermore, it has been shown that disabling APM can cause some drives
> to over-heat, so they will be definitely damaged if you do that, and by
> putting extra load on the battery you will be reducing its operational
> lifespan, too.

All I've seen is some 3-degree increases in temperature. I understand
that people might worry, but can you point me to where's the evidence of
actual overheating?

> Rolling out the workaround on every system, including those not
> currently affected, is a mistake. You will make the experience worse
> for some people (e.g. me. I have fixed all my idle-writers manually - my
> disk sleeps like a baby now), and you will make it possible for...

Read more...

Revision history for this message
Bart Samwel (bart-samwel) wrote :

Brian Visel wrote:
>> It is not the place for the operating system to save the user from
>> themselves.
>
> Whose opinion is that? I would argue that it is, indeed the operating
> system's place to save the user from themselves.

...and especially w.r.t. hardware, I might add! The OS is supposed to be
an isolation layer between software and hardware, and while the user
maybe allowed to screw up his software install, the OS should keep the
hardware whole at all times...

> it should be looked into. The basic statement is that hard disks will
> overheat if they don't sleep, yes? This can be checked with smartctl's
> value/worst/thresh settings, perhaps it would be a good idea for people
> who *are* running with systems that have APM disabled to post their
> value/worst/thresh for temperature? While I prefer to do some research
> before moving into the unknown, I'll take a probably-safe unknown over a
> definitely-unsafe known.

I get:

Device Model: Hitachi HTS541616J9SA00
[...]
194 Temperature_Celsius 0x0002 144 144 000 Old_age Always
       - 38 (Lifetime Min/Max 15/45)

On my Dell Inspiron 9400 with hdparm -B 254. No trouble here.

> Congratulations for fixing all of your idle-writers manually. It still
> stands that they system by default installs many idle-writers -- and
> either those should be fixed by default, or the system should account
> for its own default behavior in a way that prevents damage to the
> hardware.

Not only that, but I'd say that even if the distro has fixed its
default-install idle-writers or even all of its idle-writers, it's still
not safe from idle-writers if it hasn't done anything about the
underlying problem. People can, and will, install their own software,
and they *will* be idle-writers!

> I think a more ideal situation would be a smartctl daemon that checks
> for problematic usages, and adjusts settings accordingly, with either
> longevity or power saving in mind, depending on whether the system is on
> AC or on battery, as well as providing a user warning on drive-fail
> situations.

Note that I've just received a report from a laptop-mode-tools user who
noticed that the smartd check at 30-minute intervals would spin up his
disk. So the checks can't be _that_ dynamic, or it may again spin up
disks and unpark heads. :-/

Cheers,
Bart

Revision history for this message
Chris Jones (cmsj) wrote :

Bart Samwel wrote:
>> Whose opinion is that? I would argue that it is, indeed the operating
>> system's place to save the user from themselves.
> ...and especially w.r.t. hardware, I might add! The OS is supposed to be

You are actually all talking about "saving" users from their hardware
vendors, not themselves. They didn't set the APM behaviour.

--
Chris Jones

Revision history for this message
Bart Samwel (bart-samwel) wrote :

Chris Jones wrote:
> Bart Samwel wrote:
>>> Whose opinion is that? I would argue that it is, indeed the operating
>>> system's place to save the user from themselves.
>> ...and especially w.r.t. hardware, I might add! The OS is supposed to be
>
> You are actually all talking about "saving" users from their hardware
> vendors, not themselves. They didn't set the APM behaviour.

ACK that, we are talking about a hardware problem here. And it's not
Ubuntu's fault that the hardware slowly self-destructs. IMO the hardware
vendors have fucked up royally here. Still, drivers in Linux are usually
full of hacks to work around fuckups by hardware vendors. It's not much
use pointing our fingers at the hardware vendors if the hardware is
already out there, we should just work around the quirks like we always
do...

Revision history for this message
Skippy le Grand Gourou (lecotegougdelaforce) wrote :

Please have a look at this : http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=448673#31

This bug seems fixed for Debian as well since more than 10 days...

Revision history for this message
Andrea Corbellini (andrea.corbellini) wrote :

The Ubuntu Laptop Team is not responsible for the acpi-support.

Changed in acpi-support:
assignee: ubuntu-laptop → nobody
Revision history for this message
Przemek K. (azrael) wrote :

Skippy: this Debian bug is already in the bugwatch. We all know about it.

Changed in acpi-support:
status: New → Incomplete
Revision history for this message
Przemek K. (azrael) wrote :

When Ubuntu moves to pm-utils this Howto might be useful:
http://en.opensuse.org/Disk_Power_Management

Revision history for this message
Skippy le Grand Gourou (lecotegougdelaforce) wrote :

Sorry for the inconvenience... But so why did this bug just changed to critical and comments are so active when Debian claims it is fixed for them since two weeks ??? AFAIK, the difference between Debian and Ubuntu is not so huge...

Revision history for this message
Brian Ealdwine (eode) wrote : Re: [Bug 59695] Re: High frequency of load/unload cycles on some hard disks may shorten lifetime

>From what I gather, Ubuntu synchronizes with Debian periodically, and
individual packages are sometimes synchronized as well. But it is not
an immediate process. It would probably be a good idea to synch this
change over to Ubuntu, but I'm not sure who's responsible for/capable of
that.

Revision history for this message
Bart Samwel (bart-samwel) wrote : Re: [Bug 59695] Re: High frequency of load/unload cycles on some hard disks may shorten lifetime

Brian Visel wrote:
>>From what I gather, Ubuntu synchronizes with Debian periodically, and
> individual packages are sometimes synchronized as well. But it is not
> an immediate process. It would probably be a good idea to synch this
> change over to Ubuntu, but I'm not sure who's responsible for/capable of
> that.

In fact, for acpi-support Ubuntu is the upstream and Debian is the
downstream.

Cheers,
Bart

Revision history for this message
Brian Ealdwine (eode) wrote : Re: [Bug 59695] Re: High frequency of load/unload cycles on some hard disks may shorten lifetime

Ah, corrected.

Revision history for this message
ubuntu_demon (ubuntu-demon) wrote :

Bart Samwel can you please notify us when you have added the "use an apm of 128 while on battery" into Debian's acpi-support ?

I think we can increase the chance that this fix makes it into Gutsy's acpi-support if someone makes a debdiff when Debian's acpi-support has included the "use an apm of 128 while on battery" part of the fix. (maybe we need debdiffs for Dapper,Edgy,Feisty too if the debdiff for Gutsy gets included)

If Hardy will use pm-utils ( https://blueprints.launchpad.net/ubuntu/+spec/pm-utils-integration ) then we need to make sure this fix will also make it into pm-utils. Thanks Przemysław Kulczycki for giving us this link : http://en.opensuse.org/Disk_Power_Management

Revision history for this message
Mark Thomas (mark-ubuntu-efaref) wrote : Re: [Bug 59695] Re: High frequency of load/unload cycles on some hard disks may shorten lifetime

We are talking about wear and tear, not drives catching fire. It's
expected that a drive will break eventually, and load cycling is just a
(relatively new) way that drives can reach end of life.

However, the crux of this bug is that Ubuntu is, by default, causing
_excessive_ wear and tear on drives. We can fix that by not causing that
wear and tear.

You can't stop a user from using their hardware, even if using it will
wear it out eventually.

Disabling APM disables a whole slew of features, not just head parking.
Features I paid for, and that hard disk engineers spend their time
developing. It's the proverbial hammer to this problem's loose screw, and
will probably only succeed in reducing the disk's lifespan.

You can't know what disabling APM disables for every drive ever made and
ever to be made will do. Who knows (other than the manufacturer, whom we
are overriding)? -B 254 might very well disable wear-levelling on next
year's flash drives. Messing around with APM settings is not something an
OS should be doing by default.

Revision history for this message
ubuntu_demon (ubuntu-demon) wrote :

Here's a suggestion to prevent heat problems :

* while on battery : use apm 128
* while on AC and disk temperature <= 58 degrees celcius : use apm 254
* while on AC and disk temperature > 60 degrees celcius : use apm 128
* while disk temperature of 59 and 60 degrees don't change the apm. So apm can be 254 if the temperate was below 58 previously and apm can be 128 if temperature was above 60 degrees previously.

I would appreciate help to improve the ugly unofficial workaround to include something like this to make it less ugly.

The ugly unofficial workaround (use this only if you are heavily affected) :
http://ubuntuforums.org/showpost.php?p=3675960&postcount=26

The support thread for the Load_Cycle_Count issue :
http://ubuntuforums.org/showthread.php?t=591503

Revision history for this message
SirLancelot (lukaszgraczyk) wrote :

Is there any simple way to measure disk temperature? Something like command
or something? I'm using Your Ugly Fix solution:

http://ubuntuforums.org/showpost.php?p=3675960&postcount=26

And everything looks good but I don't know how to measure HDD temperature.
Could You tell me or put this information into Your Ugly Fix description?

Revision history for this message
Chris Jones (cmsj) wrote : Re: [Bug 59695] Re: High frequency of load/unload cycles on some hard disks may shorten lifetime

Hi

SirLancelot wrote:
> Is there any simple way to measure disk temperature? Something like command

There is hddtemp, and some systems (e.g. mine) expose the information
through platform-specific ACPI. I have no idea if it's guaranteed to be
a) present, b) correct across all disks though, and I personally very
much agree with Mark Thomas' assessment.

--
Chris Jones

Revision history for this message
ubuntu_demon (ubuntu-demon) wrote :

to SirLancelot :

sudo aptitude install hddtemp
hddtemp /dev/sda

You can also use sensors-applet to read it out graphically for your gnome-panel :
$sudo aptitude install hddtemp sensors-applet

This bug report is not meant for support. Please use the support thread for the Load_Cycle_Count issue :
http://ubuntuforums.org/showthread.php?t=591503

Revision history for this message
SirLancelot (lukaszgraczyk) wrote : Re: [Bug 59695] Re: High frequency of load/unload cycles on some hard disks may shorten lifetime

Thank's! My hddtemp score is:

/dev/sda: ST9120821A: 42°C
>

So I could stay with Ugly Fix without any changes.

Is there any chance for the official fix? Bug becomes Critical and there is
still nothing better than Ugly Fix by ubuntu_demon.

Revision history for this message
Fabien Lusseau (fabien-beosfrance) wrote :

We could use laptop-mode to correct this bug properly ...

Revision history for this message
Chris Jones (cmsj) wrote : Re: [Bug 59695] Re: High frequency of load/unload cycles on some hard disks may shorten lifetime

Hi

ubuntu_demon wrote:
> * while disk temperature of 59 and 60 degrees don't change the apm.

60 seems to be a fairly common *maximum* operating temperature for
disks. Allowing it to rest at 59/60 seems like a bad idea.

Hitachi quote that (with their drives) for every degree you go above the
maximum temperature the failure rate rises 2-3%.
If your drive gets to 60 and stays there, you are leaving basically no
headroom and it may well rise above the maximum rating until your "fix"
notices and enables a power saving mode, which may well take some time
to bring the temperature down.
If your drive were rated for a maximum of 55 degrees and we allow it to
run at 60, the failure rate could potentially be 15% higher than normal,
all in the name of fixing something (head unparks) that probably wasn't
a problem in the first place.

FWIW, I forgot to mention in my previous post that the temperature
information is often also present in SMART output.

--
Chris Jones

Revision history for this message
Joel Wirāmu Pauling (aenertia) (aenertia) wrote :

Confirmed behaviour in fedora 8, on dell xps m1210 with both 80gb hitachi and 120gb seagate. On resume drive aggressively spins down.

Fix:

add "99-hdd-spin-fix.sh"

to

/etc/pm/config.d
/etc/pm/sleep.d
/etc/pm/power.d

where "99-hdd-spin-fix.sh"

Contains the lines:

#!/bin/sh
hdparm -B 255 /dev/sda

Where /dev/sda is the effected disc.

Changed in acpi-support:
status: Incomplete → Confirmed
Revision history for this message
Przemek K. (azrael) wrote :

Fedora doesn't have acpi-support package.

Changed in acpi-support:
status: Unknown → Fix Released
Changed in laptop-mode-tools:
status: Unknown → In Progress
Revision history for this message
Przemek K. (azrael) wrote :
Changed in pm-utils:
status: Confirmed → Unknown
Changed in pm-utils:
status: Unknown → Invalid
Revision history for this message
ubuntu_demon (ubuntu-demon) wrote :

Improved suggestion to prevent heat problems :

For drives which support hddtemp check disk temperature regularly (each minute?).
* while on battery : use apm 128
* while on AC and disk temperature <= 58 degrees celcius : use apm 254
* while on AC and disk temperature >= 59 degrees celcius : use apm 128

Most disks should be able to handle temperatures up to and including 60 degrees celcius (within the operating temperature spec) so switching to an apm of 128 when the temperature is 59 degrees should be safe.

Chris Jones, Bart Samwel,others what do you think ?

Revision history for this message
Bart Samwel (bart-samwel) wrote :

ubuntu_demon wrote:
> Improved suggestion to prevent heat problems :
>
> For drives which support hddtemp check disk temperature regularly (each minute?).
> * while on battery : use apm 128
> * while on AC and disk temperature <= 58 degrees celcius : use apm 254
> * while on AC and disk temperature >= 59 degrees celcius : use apm 128
>
> Most disks should be able to handle temperatures up to and including 60
> degrees celcius (within the operating temperature spec) so switching to
> an apm of 128 when the temperature is 59 degrees should be safe.
>
> Chris Jones, Bart Samwel,others what do you think ?

Sounds reasonable. Each minute *might* not be enough though, I don't
know how fast these temperatures go up. And let's just hope that there
aren't any drives out there which spin up as a result of hddtemp...

Revision history for this message
Brian Ealdwine (eode) wrote : Re: [Bug 59695] Re: High frequency of load/unload cycles on some hard disks may shorten lifetime

I think we should check to ensure apm of 128 has the effect we're looking for, but other than that, looks good.

Revision history for this message
Wouter Deconinck (wdconinc) wrote :

My hard disk spins up when you call hddtemp. Sorry to spoil the fun. Cheers!

# hdparm -C /dev/sda && hddtemp /dev/sda && hdparm -C /dev/sda

/dev/sda:
 drive state is: standby
/dev/sda: TOSHIBA MK8034GSX: 41°C

/dev/sda:
 drive state is: active/idle

Revision history for this message
Bart Samwel (bart-samwel) wrote : Re: [Bug 59695] Re: High frequency of load/unload cycles on some hard disks may shorten lifetime

Wouter Deconinck wrote:
> My hard disk spins up when you call hddtemp. Sorry to spoil the fun.
> Cheers!
>
> # hdparm -C /dev/sda && hddtemp /dev/sda && hdparm -C /dev/sda
>
> /dev/sda:
> drive state is: standby
> /dev/sda: TOSHIBA MK8034GSX: 41°C
>
> /dev/sda:
> drive state is: active/idle

Hi Wouter,

Did you make sure that hddtemp was in the cache before doing this? To be
  sure you could do someting like:

hddtemp /dev/sda
<wait until hard drive spins down>
hdparm -C /dev/sda && hddtemp /dev/sda && hdparm -C /dev/sda

Cheers,
Bart

Revision history for this message
Wouter Deconinck (wdconinc) wrote :

Hi Bart,

I did indeed consider that; see below. With btrace I checked that it is hddtemp that is accessing the hd and causing it to spin up. FWIW, smartctl has the same behavior (as you already mentioned in <a href="https://bugs.launchpad.net/ubuntu/+source/acpi-support/+bug/59695/comments/253">comment 253</a>).

Cheers
Wouter

# hdparm -S1 /dev/sda && hddtemp /dev/sda && sleep 10 && hdparm -C /dev/sda && hddtemp /dev/sda && hdparm -C /dev/sda

/dev/sda:
 setting standby to 1 (5 seconds)
/dev/sda: TOSHIBA MK8034GSX: 26°C

/dev/sda:
 drive state is: standby
/dev/sda: TOSHIBA MK8034GSX: 26°C

/dev/sda:
 drive state is: active/idle

# hdparm -S1 /dev/sda && smartctl -a /dev/sda | grep Load_Cycle_Count && sleep 10 && hdparm -C /dev/sda && smartctl -a /dev/sda | grep Load_Cycle_Count && hdparm -C /dev/sda

/dev/sda:
 setting standby to 1 (5 seconds)
193 Load_Cycle_Count 0x0032 089 089 000 Old_age Always - 114151

/dev/sda:
 drive state is: standby
193 Load_Cycle_Count 0x0032 089 089 000 Old_age Always - 114152

/dev/sda:
 drive state is: active/idle

Revision history for this message
xmNeO (megahacker-neo) wrote :

I managed this problem by adding hdparm -B 254 /dev/sda to /etc/rc.local

Did anyone tried this one out,too?

Revision history for this message
ubuntu_demon (ubuntu-demon) wrote :

to xmNeo :

The support thread for this issue is here :
http://ubuntuforums.org/showthread.php?t=591503

Be sure to read the first post and the "README FIRST links" :
http://ubuntuforums.org/showpost.php?p=3733762&postcount=1

Revision history for this message
ubuntu_demon (ubuntu-demon) wrote :

In order to be able to make apm 254 work for some drives (particularly certain samsung drives) people need to do :
sudo smartctl -o on /dev/sda

At least two people have confirmed this. For example see http://ubuntuforums.org/showpost.php?p=3672087&postcount=18

Revision history for this message
CptSkyhawk (captainskyhawk) wrote :

I fixed this on all of my laptop drives my adding the "/dev/sda { apm = 254}" into /etc/hdparm.conf after enabling hdparm in System > Administration > Services.

Seems to work -- my load count hasn't increased hardly at all since. Unfortunately, I didn't get it before my load count on one of my drives (one that's only a year and half old) has reached north of 1.2 million.

Get this fix out quick!

Revision history for this message
ubuntu_demon (ubuntu-demon) wrote :

to Bart Samwel and all others who are interested :

For some people an apm of 254 doesn't work. For example :
http://ubuntuforums.org/showpost.php?p=3915142&postcount=553

Maybe an apm of 255 works for some of those people.

For others "sudo smartctl -o on /dev/sda" is needed in order to be able to make apm 254 work for some drives (particularly certain samsung drives).
At least two people have confirmed this. For example see http://ubuntuforums.org/showpost.php?p=3672087&postcount=18

From :
https://bugs.launchpad.net/ubuntu/+source/hdparm/+bug/172287/comments/1 :

[quote=Matthias Dietrich]
Looking at hdparm's code, we can see that the value of 255 will NOT be sent to the harddrive, but it will send the "disable APM"(0x85) command instead of "set APM to xxx" (0x05).
[/quote]

Revision history for this message
ubuntu_demon (ubuntu-demon) wrote :
Revision history for this message
Mathieu HAVEL (mathieu-havel) wrote : no fix working !

I have DELL Latitude D830 since 2 days now with a Samsung HM12HII drive.

I have this bug of too much clicks (I hear them 5-10 times per minute in average).

So I tried each solution found on that bug report and many other sources (mainly blogs that are saying same things than here since it envolved the same people) : hdparm.conf with both -B 254 and 255, laptop_mode enable with CONTROL_HD_POWERMGMT=1, and finally (I had hope when reading the previous post) the trick for some Samsung owner (smartcl -o on /dev/sda)

Unfortunately the problem remains the same whatever the ugly fix is in use. Of course I checked both Load_Cycle_Count raw value and Worst/Tresh values, and checked that one increment is related to one click heard.

Here are some values :

225 Load_Cycle_Count 0x0012 099 099 000 Old_age Always - 748
9 Power_On_Hours 0x0032 099 099 000 Old_age Always - 1154

One more thing : the hdparm -I /dev/sda command give me this strange thing (also reported by other people) :

Advanced power management level: unknown setting (0x0000)

I know that 2 days is very short time, but 748 sings already very bad for HDD life time ! Just to compare, I have an old laptop (Asus) with a 2 months Hitachi drive, and I have a Load_Cycle_Count of 192, stabilized (I cannot hear any click).

So, as it is mentioned here, fixes proposed here are not solution, at least for me, but overall, it shows us that we did not understand the problem (I mean real causes, process involved...).

Hope we'll find a good (true) solution for that really bad problem !

Mathieu

Revision history for this message
Brian Ealdwine (eode) wrote : Re: [Bug 59695] no fix working !

Your drive probably has something unique (and probably nonstandard)
about its power management settings that is preventing the hdparm
setting from taking. Whether it's a bug or an issue of the drive maker
not following standards, it appears hdparm isn't working quite right on
your system in regard to APM, and you should file a report on the hdparm
package.

I think the solutions we've been working toward here do actually work,
but not in cases where the power management cannot be controlled
(because both the issue and the workaround fix are directly related to
power management).

Revision history for this message
Mathieu Marquer (slasher-fun) wrote :

Mathieu, you have less than one cycle for each hour of power on...

Revision history for this message
Sami Haahtinen (ressu) wrote :

On Wed, 2007-12-12 at 23:24 +0000, Brian Visel wrote:
> Your drive probably has something unique (and probably nonstandard)
> about its power management settings that is preventing the hdparm
> setting from taking. Whether it's a bug or an issue of the drive maker
> not following standards, it appears hdparm isn't working quite right on
> your system in regard to APM, and you should file a report on the hdparm
> package.

It might have something to do with the hardware indeed. I'm using a Dell
Latitude D610 and i get the same error when checking the APM parameters.
Even still the clicking stopped with -B 254, i haven't checked the
numbers yet so my mind could be playing tricks on me.

> I think the solutions we've been working toward here do actually work,
> but not in cases where the power management cannot be controlled
> (because both the issue and the workaround fix are directly related to
> power management).

The current solution appears to be good and once the final configuration
is settled it should be put in to place. The problem is that we should
have a way to detect broken hardware and notify the user about the
possible problem. Once this solution is labeled as working most of us
will continue working without any more thought about the issue while the
hardware could still be subjected to excess stress.

- S

--
Sami Haahtinen <email address hidden>

Revision history for this message
Brian Ealdwine (eode) wrote :

Once this solution is labeled as working most of us
> will continue working without any more thought about the issue while the
> hardware could still be subjected to excess stress.

*nod* Good point.

Revision history for this message
Mathieu HAVEL (mathieu-havel) wrote : Re: no fix working !

@slasher-fun : Well, I do have a huge amount of Load_Cycle_Count, since I hear them 5 to 10 times in a minute (today I have a total value of 1711 !!). I don't know how the Power_On_Hours is counted... With actual increase rate, my HDD will die within one year (he is only 3 days old)!

@Brian Visel and Sami Haahtinen : it is a good point that my HDD has (maybe) a nonstandard APM, but I checked/changed BIOS settings and used the Samsung tool (HUTIL) to check and set the APM settings (which are, since the beginning, set to non-agressive values, equivalent or equal to -B 254)... That's why I do not understand the cause of my problem, and make me say that there is maybe another cause to that "bug" which could come from a bad setting or bad deamon use in Ubuntu, as already suggested here.

It would be very usefull to know how many people have similar problem than me, to see if "just" using hdparm is a "good" (clean) solution to that f*** bug.

Mathieu

Revision history for this message
Brian Ealdwine (eode) wrote : Re: [Bug 59695] Re: no fix working !

Mathieu:
Yes, your load cycle count seems to be increasing rapidly. However, the tool
that is used to affect this is either being used improperly by you, or isn't
able to handle the disk you have (likely because the disk is nonstandard).

Using the disk manufacturer's tool to check the settings of that manufacturer's
hard disk in no way even vaguely implies that your disk is standard.

If your system cannot be controlled through hdparm, then there is nothing that
I know that can do anything for your clicking problem, even if it is the same
issue as everyone else is having -- specificly, hdparm is used to control your
APM settings. If the tool which is used to change such things is broken, then
there is little you can do other than talk to the toolmaker, and see if he knows
how to fix it. You have provided me, basically, with two pieces of information:

* Your HD is clicking like many others do
* The tool used to change your settings and modify this behavior doesn't work
  for you, even though it works for many other people.

therefore, your options are:
* Use another tool
* Check to make sure you are using the existing tool properly
* Go to the toolmaker(s) and ask if (s)he will fix it

Since I know of no other tools to change the low-level settings of your hard drive
while Linux is running, it might be a good idea to try the second and third options
mentioned above -- that is, verify that you are doing your part correctly, then go
to the toolmakers (file a bug report with the hdparm package).

> It would be very usefull to know how many people have similar problem
> than me, to see if "just" using hdparm is a "good" (clean) solution to
> that f*** bug.

No, it is not a great solution. But it is a solution that greatly
improves the situation, works in most cases, and has comparatively few
detriments. Apparently, yours is not one where it does work, because a
different problem interferes. Again, I would suggest that, after
verifying that you have followed fix instructions correctly, and that it
doesn't work, you should work with with the hdparm packager(s)/coder(s)
to try and figure out whether or not they can help you.

Revision history for this message
donzilluh (donzilluh) wrote :

My laptop was showing these symptoms. It's a HP DV6645us bought only 2 months ago on Oct 10th. I just recently installed Ubuntu and stumbled upon this article with only 9 hours of uptime. So I feel as I have lucked out. This is a very harmful bug though and needs to be incorporated into the automatic software updates somehow. I am a linux semi-noob and this one truly scared me.

  9 Power_On_Hours 0x0012 099 099 000 Old_age Always
     866

This shows a rate of almost 100 cycles per hour. My disk's total load cycle count is only 24,617, considering this is from only 2 months of use and 9 hrs of gutsy gibbon uptime I am very thankful Gilles Schintgen discovered this bug.

Revision history for this message
Mathieu HAVEL (mathieu-havel) wrote : Re: no fix working !

Brian,

I do agree with you... it seems that hdparm has no effect on my HD APM settings.

To answer your questions, I think I'm using well hdparm -- I fixed the click problem of a friend computer by this way -- and the Samsung tool is working (I used 2 differents version, both on bootable CD's).

So your advice to contact hdparm team to see if they know about that issue is my best solution, as you said.

Thanks a lot for these discussions, and keep the pressure on the Ubuntu team in order to manage this problem in a better/safer way than now (and by default). Unfortunatly, I think this bug cause(d) prejudices to Ubuntu distribition, even if it is not specific to it... more and more people using Linux (and especially Ubuntu), went to this world to see "the other side" with "windows skills" and do not want to spend time with the many hand settings to do in their computer (it is not my case ;) ): they just want a "ready to use solution without configuration". And it was a goal of Ubuntu : attrack more people from other OS to Linux world, showing them it is a serious option ! They may be disapointed by such big problem and "never" come back to Linux !

Mathieu

Revision history for this message
romassi (romassi1977) wrote :

I finally fixed on my laptop (Acer Aspire 1662, Kubuntu Gutsy 7.10 - HD Hitachi Travelstar 60 GB) by editing the file:

/etc/hdparm.conf

with:

/dev/hda {
apm = 255
spindown_time = 255
}

No more parking at all and non problems of over-heating.

My girlfriend's laptop (Toshiba A100, Kubuntu Gutsy 7.10 and HD Toshiba 120 GB) reached about 26000 cycles in about 110 hours of use.
The option below (apm=255) seemed not to do anything. I tried apm = 254 and it stopped clicking at all but the operating temperature of HD was increased dramatically. So I choosed a value of apm = 210 which caused a good compromise between parking and over-heating.

I hope my personal experience could be useful...

Revision history for this message
Brian Ealdwine (eode) wrote : Re: [Bug 59695] Re: no fix working !

Matthieu:

I agree that this is an issue that has probably shed more negative light
on Ubuntu specificly than on any other distribution. The best way that
we can avoid a fiasco such as this is to fix the problems that come up
as soon as possible. The evidence of the length of time it took to
address this bug in a way that makes things safer for the users (even
though it's not a complete solution, yet) indicate there are problems
with communication in the Ubuntu community, but there are people pushing
to fix that in one way or another -- through launchpad changes, etc..
Hopefully communication will improve, and this sort of thing won't be
prone to happening again.

Andrea Corbellini explained to me the particular way this bug went awry
-- it was misassigned, then its priority was changed, so it slipped off
into bug-purgatory for quite a while. However, that shouldn't really be
possible, when there are so many trying to get action on it.

There are quite a few people trying to get Launchpad open-sourced, so
that work on it moves faster -- but Canonical needs to implement its
business plan, else there are a great many other things that will go
awry with Ubuntu -- and keeping Launchpad closed for now is a part of
that plan. But, it is also a part of the plan to open-source it. In
the meantime, we can file bugs (general or specific) on launchpad itself
that try to address communications issues in Launchpad, finding examples
of bugs that have run into particular issues, and filing reports on
those issues.

Revision history for this message
donzilluh (donzilluh) wrote :

I realized the result it returned "9" was not my uptime hours. Tired noob mistake. I am just curious if my problem should be fixed completely by adding the 99-hdd-spindown-fix.sh to the 3 directories and altering the laptop-mode config to CONTROL_HD_POWERMGMT=1 and also APMD_SPINDOWN=90 in the *other file (my memory does not serve the exact name correctly). My load cycle count stopped increasing by a great amount. Now it's less than 1 to about 5 minutes. This means I should be alright? Because I noticed my hdd still blinks while it should just be idle. Is this a normal happening? I also used the hitachi live cd and changed the APM settings to highest (254) Does this mean the -b 255 still works even though this apparently goes to 254? A lot of confusion in my mind about this bug. It's hard for me to understand completely as I'm simply that new to ubuntu. I would just like that piece of mind, I need to know for sure by using ubuntu it will not decrease my laptop longevity.

Revision history for this message
Brian Ealdwine (eode) wrote : Re: [Bug 59695] Re: High frequency of load/unload cycles on some hard disks may shorten lifetime

This is not a support forum. Please do not use it as such. There are
multiple links in multiple posts on this bug that point to forum posts
related to this bug. Please search for answers to your requests before
you post questions.

Brian Ealdwine (eode)
description: updated
Brian Ealdwine (eode)
description: updated
Revision history for this message
Tzvetan Mikov (tmikov) wrote : Re: [Bug 59695] Re: High frequency of load/unload cycles on some hard disks may shorten lifetime

On Dec 14, 2007 2:18 PM, Brian Visel wrote:
>[...]
> Reasonable Limits / Criteria for a fix:
> * There should be fewer than ~15 load cycles per hour, except during heavy usage while on battery.
> * This provides a life expectancy of over four years, which is reasonable for a hard disk.

May be I am just nitpicking, but I think that four years life
expectancy is _not_ reasonable at all. It is absurdly short (even
ignoring the moral and environmental aspects of a consumerist economy
:-) . I own as well as work with many computers and hard drivers older
than four years, and all are in working order. Nobody sane would buy
or use a product which is _designed_ to fail in four years. Perhaps
the business model of the hard drive manufacturers relies on frequent
HDD replacements, but it is not the OS-es place (let alone a free OS
like Ubuntu) to re-infoirce that model.

The life of a hard drive is not controlled by a single parameter, so I
think there should be a safety margin of at least two in all known and
controllable ones (unless the manufacturer specs already include that,
in which case I retract my point). The hardware+OS combo should be
designed to offer at least 10 years life (obviously, unless the laptop
gets dropped) - otherwise, we all know very well, it is just going to
break in two years and exactly when you most need it :-)

regards,
Tzvetan

maor (maors)
description: updated
Revision history for this message
Brian Ealdwine (eode) wrote :

----- Original message -----
From: Leann Ogasawara <email address hidden>
** Tags added: qa-hardy-list

-- end quote --

w00t! Thanks, Leann!

Revision history for this message
Brian Ealdwine (eode) wrote :

You're probably right on that. I'll edit the description when i get to a computer. I've wanted to flesh that out anyway, re: ac vs battery behavior, so i'll kill two stoned birds when i edit that. ..er, two birds with one stone. 'course, someone else can edit it too, if they like. ..But i've got a rather clear picture of the issues, and don't mind editing it myself.

From: Tzvetan Mikov <<email address hidden>
May be I am just nitpicking, but I think that four years life
expectancy is _not_ reasonable at all. It is absurdly short (even
ignoring the moral and environmental aspects of a consumerist economy
:-) . I own as well as work with many computers and hard drivers older
than four years, and all are in working order. Nobody sane would buy
or use a product which is _designed_ to fail in four years. Perhaps
the business model of the hard drive manufacturers relies on frequent
HDD replacements, but it is not the OS-es place (let alone a free OS
like Ubuntu) to re-infoirce that model.

The life of a hard drive is not controlled by a single parameter, so I
think there should be a safety margin of at least two in all known and
controllable ones (unless the manufacturer specs already include that,
in which case I retract my point). The hardware+OS combo should be
designed to offer at least 10 years life (obviously, unless the laptop
gets dropped) - otherwise, we all know very well, it is just going to
break in two years and exactly when you most need it :-)

regards,
Tzvetan

--
High frequency of load/unload cycles on some hard disks may shorten lifetime
https://bugs.launchpad.net/bugs/59695
You received this bug notification because you are a direct subscriber
of a duplicate bug.

Revision history for this message
maor (maors) wrote :

dell has a mailling list for linux support, did anyone considered asking them how they handled the problem?

Revision history for this message
Mathieu HAVEL (mathieu-havel) wrote :

First, thanks for good comments Brian....

I have a complete business support in DELL, and I called them friday to tell them about the problem. Here is their solution :
"We're coming to replace your HD".

So, at least in the Business support, they do not consider the problem ! Pretty strange when we know that they sell some of their computer with Ubuntu or Red Hat on it !

I should test (if I have time during christmas) to exhange my HD from my old computer (which is not suffuring the bug) with the new one in the DELL. I would like to see if on it I can manage to "ugly fix" it or if there is a problem at all.
This could tell us if some HD are completely out of control (I mean, we cannot change the behavior).

Mathieu

Revision history for this message
Anonymous (unquoteveracity-deactivatedaccount) wrote :

@maor and Mathieu HAVEL

If you are interested in getting Dell to replace affected hard drives, you may wish to promote this idea on Ideastorm:
http://www.ideastorm.com/article/show/75651/Replace_worn_hard_drives_of_Ubuntu_PCs

It requests that Dell replace not only hard drives that die from this bug, but also hard drives that are greatly affected before a fix is implemented. In my case, my hard drive accumulated more than 450,000 load cycles before I applied the fix, so I think it and other drives like it deserves to be replaced.

Revision history for this message
Mathieu HAVEL (mathieu-havel) wrote :

Well, Dell went to replace my hard drive, and they seem to be aware of the problem since they replace it by another one (a Seagate ST91208220AS) on which I can apply partly the bug fix :
* with -B 255 it completely stops the parking/unparking cycle
* with -B 254 it does nothing.

The my previous one was a really strange case, and more when we know that the Samsung was recognized in the SMART database, and the Seagate is not !

Last but not least, hdparm is always giving me the BIOS value for PowerManagement (set to 254) but this value is NOT applied by default on Ubuntu, and if I change it to 255, hdparm still indicates 254... Here I do not understand : either I have a bad configuration or either the problem is not "that simple" as the ugly fix let us suggest !

My conclusion is that, as I said, the ugly fix works (fortunatly) for about 95% of cases, but it is not fixing directly the "real" problem : I think it is not yet a direct solution. We have to find (and define) the true cause of this "too much" cycling.

I hope such information can help, and I am looking forward to give more if needed.

Mathieu

Revision history for this message
Matthias Dietrich (matthias-dietrich) wrote :

Mathieu:

In fact 255 is not a legal value for APM. The ATA/ATAPI spec states clearly that 255 is reserved. The APM parameter only accepts values up to 254, so hdparm will never read out 255 as a value for APM. However hdparm accepts -B 255, and in such case, it will send a "disable APM" command to the harddisk. So you may perfectly have "APM=254" while APM is disabled. The APM setting is just kept in the drive, but will have no effect, as APM is generally disabled.
Now hdparm is not completely right : the ATA/ATAPI spec also states that the "disable APM" command may not be supported on all drives.

To sum up, there are mainly two sorts of harddrives:
- those accepting the "disable APM" command. For these drives, you may still read out APM=254 (or whatever you set previously) after applying -B 255 (look at hdparm's output, it will tell you that APM is disabled).
- those not accepting the "disable APM" command. These drives will most likely use 254 as "no APM" setting.

You are right by saying that we did not really fix anything with this workaround.

I made some investigations on my brand new laptop, which had Windows Vista preinstalled. Using the win32 port of hdparm I compared the data returned by the "identify" ATAPI command, which is more or less what hdparm -I returns. I just did this in "raw" format to avoid hdparm's interpretations messing around. The harddisk settings (APM, and so on) are the same under Vista and Ubuntu, but under Vista, there is no clicking. So either Windows sends additional commands to the drive, or Linux does it, but I don't think it is just a matter of "default settings". At least the APM settings are the same (APM active, value = 128).

There is an ATAPI command which could produce the same effects ("idle immediate with unload"). I wonder whether this is used in the kernel, or whether the harddisk's firmware could interpret a simple "idle" command as "idle immediate with unload" under certains circumstances.

Matthias

Revision history for this message
Brian Ealdwine (eode) wrote : Re: [Bug 59695] Re: High frequency of load/unload cycles on some hard disks may shorten lifetime

Any estimate on when / if the partial fix will get pushed as an update
for gutsy? There are a lot of people out there with this who may not
even know about it, and the clock is ticking.

I could make a utility in python that would check for the issue, then
change settings if the problem is present, then apply the fix, check to
make sure it worked, apply the other setting if not, check to make sure
that worked. Either way, it would save the settings, and not try again
unless the HD has been moved to a new machine, and/or the HD has been
replaced.

I'm not so familiar with packaging, though I might be able to learn, if
I have time. I don't know if a python 'daemon' would be desirable,
anywho. But it would just take too much of my time to do that in C++...

Revision history for this message
Brian Ealdwine (eode) wrote :

Matthieu:

Your case seems inconsistent with itself:

On Sat, 2007-12-22 at 22:34 +0000, Mathieu HAVEL wrote:
> [...]they replace it by another one (a Seagate ST91208220AS) on which I can apply partly the bug fix :
> * with -B 255 it completely stops the parking/unparking cycle
> * with -B 254 it does nothing.
[...]
> Last but not least, hdparm is always giving me the BIOS value for
> PowerManagement (set to 254) but this value is NOT applied by default on
> Ubuntu, and if I change it to 255, hdparm still indicates 254... Here I
> do not understand : either I have a bad configuration or either the
> problem is not "that simple" as the ugly fix let us suggest !

..so, you are saying that '255 completely stops the parking/unparking
cycle', yet you are also saying that the drive never gets set to '255'.
If you have a particular setting that completely stops the load cycle
count from increasing -- that would be the setting to use, and your
problem is solved. If you don't, then you stated as fact that 'with -B
255 it completely stops the parking/unparking cycle', yet you had not
verified that at all. Perhaps it is merely a difficulty of
communication.

> My conclusion is that, as I said, the ugly fix works (fortunatly) for
> about 95% of cases, but it is not fixing directly the "real" problem : I
> think it is not yet a direct solution. We have to find (and define) the
> true cause of this "too much" cycling.

It has already been established that the ugly fix is:
A) only temporary
B) does not work for everyone, although it works for most
C) that in most of the cases where 255 does not work, 254 does, and vice
versa
D) That it is only *part* of a problem that must have three factors
present --
    1- a maximum load cycle count on the drive (most/all drives)
    2- Aggressive APM (Default of some BIOS software, default of some
       drives)
    3- Frequent disk activity that is not frequent enough to prevent the
       drive from parking, nor infrequent enough to let it stay parked.

Factors 2 and 3 should both be dealt with. However, removing any one of
the above contributing factors to the problem prevents the problem, and
removing factor 3 is definitely non-trivial. Therefore, we remove
factor 2 -- by increasing the delay of or turning off the head parking.

No, the 'ugly fix' is not ideal. Thus, it has a name like "ugly fix."
However, it is the most likely to be useful in a reasonable amount of
time.

Revision history for this message
maor (maors) wrote :

Matthias:

i would not relay on clicking sound to identify load unload cycles i made the same mistake,
if windows is not changing the apm value then then my guess is that ubuntu is simply accessing the hard drive too often
i do not have windows installed so i cant check it but try seeing if the load unload count is going up while using the computer if its actually going up we can assume that this is a issue with some process in ubuntu.

trying to figure out when the hard drive is being parked unparked is impossible only by the sound of the laptop. my laptop still clicks sometimes after i changed my apm but the load unload count is not going up.

Revision history for this message
jokeman (divchev) wrote :

Quick test:
Gateway 7330GZ (PC Linux, Fujitsu HD 80 GB, no clicking) with over 66,000 load cycles ~60 load cycles per hour:
with -B 255 it completely stops the load cycles.

DELL 1400 (Ubuntu, Toshiba HD 160 GB, no clicking) 4,500 load cycles ~60 load cycles per hour:
 -B 255 or -B 244 did not change the load cycles.

Same DELL with Windows XP, Sp 2: ~60 load cycles per hour (no clicks). Changing power management settings did not do anything.

Revision history for this message
Brian Ealdwine (eode) wrote :

@jokeman:
Some newer drives are very quiet about the clicking.

I would suggest inquiring on sourceforge, in hdparm's forums. The bug
of not being able to change APM levels is different. You may even want
to file a bug (or check to see if a bug already exists) with the hdparm
package.

@General
It would be a good idea to bear in mind the whole issue of drives which
cannot change their APM status. This bug still hasn't had the 'ugly
fix' released for Ubuntu, which is important to get done. But even
when that's done, the deeper issue of frequent disk access needs to be
addressed.

Any news on progress for this?

On Wed, 2007-12-26 at 20:41 +0000, jokeman wrote:
> Quick test:
> Gateway 7330GZ (PC Linux, Fujitsu HD 80 GB, no clicking) with over 66,000 load cycles ~60 load cycles per hour:
> with -B 255 it completely stops the load cycles.
>
> DELL 1400 (Ubuntu, Toshiba HD 160 GB, no clicking) 4,500 load cycles ~60 load cycles per hour:
> -B 255 or -B 244 did not change the load cycles.
>
> Same DELL with Windows XP, Sp 2: ~60 load cycles per hour (no clicks).
> Changing power management settings did not do anything.
>

Revision history for this message
Matthias Dietrich (matthias-dietrich) wrote :

maor:

In fact, I started by monitoring the load/unload parameter using hdparm with Gutsy as well as with Vista. Then I noticed that there was indeed a "click" each time the counter was increased. So at least on my computer, I can tell you when the counter goes up just by listening to the harddrive ( I need to put my ear on the keyboard, but it's easy to notice it).

Ubuntu might be accessing the disk too often, and there is probably room for improvement in the way daemons are working, however I do not believe this is the root cause of the problem. Under Vista the counter is not increased, regardless of the disk activity. So it seems Windows does not park the heads, or maybe only after a very long time. I monitored the load/unload counter on another laptop (IBM T42) running XP. It's the same, the counter is not increased. The only way I found to have the counter going up, is to shake this laptop (IBM's active protection will park the heads when a movement is detected). So Windows, be it XP or Vista has a different behaviour, although the disk's APM parameters are the same. Of course I am only speaking about my laptops. Apparently, jokeman has another experience by comparing ubuntu and XP on his Dell 1400.

Revision history for this message
jokeman (divchev) wrote :

Interesting,
More details about my machines:

Gateway 7330GZ about 18 months old, Pentium 4, 3.06 G Hz, Fujitsu PATA HD 80 GB, with over 66,000 load cycles, came with Windows XP, using PC Linux for the last 4 months only.
Tested yesterday with PC Linux and before I apply “-B 255” was ~ 60 load cycles per hour.
After: 0 load cycles per hour.

DELL VOSTRO 1400 about 10 days old, Intel® Core™ 2 Duo T7500 2.2GHz, Toshiba SATA HD 160 GB, 4,500 load cycles, came with Windows Vista, using Ubuntu for less than a day.
Tested yesterday with Ubuntu and Windows XP, Sp 2: ~ 60 load cycles per hour.
Obviously there is difference in PATA and SATA behavior or have something to do with the computer BIOS and the HD firmware it self...

Will test both with: Ubintu, PC Linux and Windows.
Did someone test what is going on with no OS?

Brian Ealdwine (eode)
description: updated
Revision history for this message
jokeman (divchev) wrote :

H-u-mm, it's interesting...
(I test only my Gateway 7330gz with PC Linux)
When I check: smartctl -d ata -a /dev/hdl | grep Load_Cycle_Count
I get ~ 1 count per minute or more.
I put the same command in a chron job to run every minute, and there is no increase any more. the HD temperature remain the same....
When I reboot, there is one count over.
Please let me know.
Interesting, indeed,
j.

Revision history for this message
Valentin Neacsu (valentin.neacsu) wrote :

Before issuing these 2 commands, I was getting roughly 1-2 load cycles per minute when the laptop sat idle:
killall -9 evolution-data-server-1.12
killall -9 evolution-exchange-storage

Now, when I'm issuing sudo smartctl -A /dev/sda after a long period of idling, I only get an increase of 1 load cycle and that's probably because I'm waking up the hdd with the command.

I've also killed:
cupsys
apmd
bluetooth

Revision history for this message
jokeman (divchev) wrote :

Please ignore my previous post.
I'm not sure what exactly happened.
Right now I have no counts when the machine is plugged in.
When is running on batteries I have ~ 17 counts per hour.
The HD temperature is 34 C.
I do not have any explanation. I do not know what I did or what happened it self.
Did I break something by executing the command?

Revision history for this message
Brian Ealdwine (eode) wrote :

@jokeman:
I don't know, but overall, that's reasonable. A laptop usually spends
at most about 1/3 of its life on battery, and it's good for the disk to
stay parked while on battery if possible (it helps protect against
impacts). Keep an eye on it and make sure that it isn't incrementing
while on AC, and the parks while on battery are few enough that it
shouldn't be a problem. I.e., no increase while on AC, ~17/hr on
battery should give you ~10 years of usable hd time, even accounting for
the load cycles that are already used.

Revision history for this message
Bruce Cowan (bruce89-deactivatedaccount) wrote :

Please read the warning at the top of this bug, namely "stop using this bug as a support forum". By doing so, you are causing all the subscibers to this bug to get useless noise messages. You also make it very difficult for the developers to take action, as it hard to see what needs to be done.

Revision history for this message
xzirrow (xzirrow) wrote :

Also want to share my researchings .
i have Toshiba laptop A100 - 912

I'd applied ugly fix thru laptop-mode by setting B param to 254 (255 doesn't work at all) . Load_Cycle stopeed ticking but It started to grow temperature .That's scares ... i have /dev/sda: TOSHIBA MK1234GSX: as you can see the SATA disk . SMART shows that 52 C is highest possible temperature for my hdd model . So than -B is 254 , the temperature is from 44 to 50 . I think it's not good at all ...

I've used hdparm -B 128 /dev/sda , and the temperature is going down to maybe 40 C , at least less than 50 . BUT it's started to ticking Load_Cycle again ...

ONLY in ONE combination it works fine !!! (May be it can help some how to solve the problem) Than some process always touching the disk , or script
with smartctl , or some torrent program , seeding torrents . Only in this case is WORKS , -B 128 , No Load_Cycle ticking , No hdd overheating .

But i think it's not the way to look for hddtemperature all day , and seeding torrents (at work for example)
Also i've tried many other ways -
1) i commented strings with $HDPARM in /etc/acpi/power.sh . SATA disk . SMART shows that 52 C is highest possible temperature
at my hdd model . So than -B is 254 , the temperature is from 44 to 50
2) i've "purged" acpi-support , and acpid .
 - No ticking AND STILL hdd overheat . in both cases .
3) I've used to set -B 200 ( or else between 128 and 254 ) - it's OR Load_Cycle ticking , OR hdd overheat always

so as i wrote before, my exploration shows what , desired effect is - B 128 /dev/sda and some process which uses the disk all the time.
it is no ticking , no overheat . How this things connected , i can't realize .

So any opinions ? where i can digg more ?
I have only one idea - than is somehow connected with ext3 . there are some ,intresting keys in laptop-mode.conf . something about SYNC . an REMOUNT with noatime (or something like it)

Hope this would help
P.S. for now i'm trying install debian lenny to see , if it's bug is really fixed as it's described on the top of this thread.

Revision history for this message
Akshay Srinivasan (akshay.srinivasan) wrote :

Confirmed on HP Pavilion dv6500 with Western Digital WD800BEVS.As stated above , the problem is "solved" by disabling APM , but the Hard disk tends to heat up.It reached a temperature of ~50 Celsius after about 15 minutes of activity.I read on the WD website that ,the heads are not parked on the disk platter , but that should mean the HDD should be capable of a lot of load/unload cycles.Can someone clarify this ?

Revision history for this message
Akshay Srinivasan (akshay.srinivasan) wrote :

I think Wester Digital drives are the worst affected.Mine has a power on time of ~104 hours with a power cycle of ~370 with a Load/Unload cycle count of 6761.That's about 65 per hour!

Revision history for this message
ogc (hackrez) wrote :

Some interesting info from my laptop. It has the same Hitachi HTS541060G9AT00 for which this bug has confirmed several times.
I am using Heron Alpha2 at present, and i never tried any of the fixes. However, bug is not happening for me even though apm level is 128 on AC (and is not changed then I unplug it), load cycle count doesn't increase even if i leave it idling for several hours.
Another interesting thing is that bug happened for me some time in the past because I have 37319 load cycles in 857 hours. That's about 44 load cycles per hour. I also use d XP, Feisty and Gutsy on this laptop.

Revision history for this message
Albert Tiu (tiualbert) wrote :

On a Thinkpad T42 with Samsung HD, the correct parameter is 254 and not 255. With 255, the load cycle increases almost every 4 or 5 seconds. With 254, it stopped. On a Gateway (not sure of the HD), 254 and 255 works. Had to change the laptop-mode.conf BATT_HD_POWERMGMT=254, LM_AC_HD_POWERMGMT=254, NOLM_AC_HD_POWERMGMT=254, also the power.sh which uses 255 as default for laptop mode enabled or disabled.

Revision history for this message
Michael Doube (michael-doube) wrote :

Some new laptops are shipping with hybrid hard drives that contain non-volatile cache memory (e.g. Sony Vaios with Seagate Momentus drives, 256 MB nvcache). One of the purposes of this technology is to prevent the hard disk spinning up when doing small intermittent writes, which would reduce the severity of cycle count increases on these drives. At the moment the kernel does not support nvcache, although the specification is freely available at t13.org. While flash memory may one day soon supersede spinning disks, in the interim only Vista supports hybrid drive technology. One way to prevent cycling on hybrid drives would be to enable nvcache functionality.
see https://bugs.launchpad.net/bugs/178654

Revision history for this message
Akshay Srinivasan (akshay.srinivasan) wrote :

I think this is linux kernel problem.Installing the latest Fedora didn't do any good , the drive kept clicking all the way through the installation , increasing by about 500 in an hour or so , after the install -without laptop-mode- it kept increasing at about ~1 per minute.

Revision history for this message
Akshay Srinivasan (akshay.srinivasan) wrote :

Shouldn't this be a bug in Linux Kernel , instead of acpi-support ?I mean ,fedora doesn't touch the BIOS stuff , so like ubuntu ,it suffers from this bug.The 64-bit version Ubuntu ,also shows this bug.

Revision history for this message
maor (maors) wrote :

this is my ambitious attempt at tackling this issue.
i created a blueprint at https://blueprints.launchpad.net/ubuntu/+spec/handlingtooagressivepowermanagment that summaries the usfull information found in this bug report (and became impossible to extract because of the high noise ratio) and brainstorming possible solutions.
i just want to clarify that i am not a Ubuntu developer and there is no guarantees that someone would actually even try to fix this bug.
i think the key to solving this issue is to simply find out how is it that windows is not suffering from this issue. i know people think windows do not suffer from this issue because it does not write to the hard drive as often as Ubuntu but according to comment https://bugs.launchpad.net/ubuntu/+source/acpi-support/+bug/59695/comments/308 that is not true and bringing Ubuntu to the same state as windows is a acceptable solution to most users.

Revision history for this message
Luca Cerutti (cerutti) wrote :

Excuse me, but I think that the whole "windows shows not this problem" approach should be entirely revised.
On my Dell Vostro 1500 with a Seagate st9160823as windows XP sp2 and ubuntu Gutsy "pre-fix" behave EXACTLY the same way with a rather aggressive (and noisy) power management.
Not only, but a thread on a italian tech forum I read, showed the same unpredictability: http://www.hwupgrade.it/forum/showthread.php?t=1595762
To summarize some posters had problems ONLY with Ubuntu, some ONLY with windows, some had problems EVEN when the laptop was AC-powered.

There is a big chance that this problem is BIOS/firmware related and it could be somewhat more useful if any of the posters could effectively test the behaviour of their systems under different condition and check hdparm result before and after trying:
1 hr with windows (idle)
1 hr with linux (idle)
1 hr with windows (benchmarking or working)
1 hr with linux (benchmarking or working)

both on battery and on AC.

I've done it before posting.

Revision history for this message
maor (maors) wrote :

well if what you say is true then thats a whole different ball game. still i find it hard to believe . make no mistake no one will be happier then me to see a big fat headline on slashdot that windows is also destroying people hard drive . i cant read Italian so tell me did they check for load/unload cycle count with smartct ? we already established that noise alone is not an indication.also no one said that on ac power the problem goes away (unless you apply the ugly fix).it is possible that this happens on windows and also on linux but maybe im missing something but i dont think it can happen only on windows.you say you tested with hdparm or do you mean smartctl and if not what is it exactly you tested?. if more people with dual boot can test properly we could get to the bottom of this.

to Matthias Dietrich: is your computer a OEM install? (maybe the manufacturer made some kind of tweak) did you use smartctl?

Revision history for this message
Brian Ealdwine (eode) wrote :

Good News, everybody! (sorry, I just like saying that..)

I don't know if this is accurate for all drives, obviously. However, on my laptop, switching from -B <254 | 255> to -B 200 decreased temperature by five degrees, without increasing load_cycle_count *at all*. This may be good news for folks who are having worries about the HD temperature. It may also be a good idea for the debian patch to be revisited, considering the concerns over HD temp.

Revision history for this message
Matthias Dietrich (matthias-dietrich) wrote :

maor:

Yes my computer came with an OEM install (it's an ASUS F3Sc with a preinstalled Windows Vista Home Premium, which I deleted now, so I will not be able to test it anymore). I cannot exclude your suggestion (namely that ASUS could have used a special tweak).
I used smartctl both under Gutsy and Windows to check the load/unload cycles, and additionaly to apply the workaround under Gutsy.

Luca Cerutti:
I did not test each case for 1 hour, but rather over periods of 10 minutes. I tried the same cases : idle/load, battery/AC, gutsy/windows. Additionally, in each case I dumped the raw "IDENTIFY" data from the harddisk, which includes the APM parameters. There was just one difference : Windows enables the so-called "device initiated interface power management", while gutsy does not, but the APM parameters were the same. This seems interesting, but this only concerns the SATA interface itself, not the disk's heads, so it is not really linked to the problem.
My observation was very simple : under windows,the load/unload cycle counter is not moving and there is no clicking sound, be it with or without load, while it is raising rapidly under gutsy. For information, the harddisk is a ST9160821AS, with firmware 3.ALC.

Revision history for this message
Akshay Srinivasan (akshay.srinivasan) wrote :

This bug is very hard disk specific.My Hard disk doesn't respond to any other value of APM other than 254!It keeps parking the heads in 253 too!

Revision history for this message
Brian Ealdwine (eode) wrote :

@Akshay:
Actually, it was mentioned above -- "255" is a reserved value, I.e.,
it's not officially used. 254 is off. 253 is low enough that it won't
happen unless you have a pretty decent period of idle time (which you
won't, because various things keep accessing the disk).

-B

Revision history for this message
Brian Ealdwine (eode) wrote :

Akshay: Pardon, misread that. My mistake.

Revision history for this message
Lorenzo Bettini (bettini) wrote :

I've done some tests on my new Dell Latitude D630 and after about 4.30 I get about 425, thus I assume I suffer from this problem, right?

With the ugly fix (actually trying 'hdparm -B 254 /dev/sda') the problem seems to get solved (no more clicks).

The hdd temperature raises to 41 C which still seems reasonable right? With the clicks it was around 36.

Revision history for this message
Akshay Srinivasan (akshay.srinivasan) wrote :
Revision history for this message
Guillermo Pérez (bisho) wrote :

I have to add the "99-hdd-spin-fix.sh" script with the hdparm -B 254 line to:
/etc/acpi/ac.d/
In addition to the other proposed directories:
/etc/acpi/suspend.d/
/etc/acpi/resume.d/
/etc/acpi/start.d/

The laptop's hd was "clicking" again after going from battery power to AC.

Revision history for this message
orellus (orelus-deactivatedaccount) wrote :

I confirm this bug on my computer...

Revision history for this message
Debian God!! (debianlife) wrote :

My hp pavillion dv6602au is also having the same problem 22800 cycles in 2 months. Can some one tell me the best solution as the ugly fix increases the hdd temperature!!!

Revision history for this message
Akshay Srinivasan (akshay.srinivasan) wrote :

As far as I have seen , a good deal lot distros are affected , but I couldn't find one query on the gentoo forums regarding the frequent parking.Could it be possible that installing pre compiled packages affects the system in a adverse way ?

Revision history for this message
Debian God!! (debianlife) wrote :

Well in my opinion, using the ugly fix removes this problem completely and the load cycle count will literally be stopped. This has got only one disadvantage, the hdd temperature is out of control (at 45 deg). In vista & xp its well below 36. Is there any fix for this????

Revision history for this message
Brian Ealdwine (eode) wrote : Re: [Bug 59695] Re: High frequency of load/unload cycles on some hard disks may shorten lifetime

>Could it be possible that installing pre compiled packages
> affects the system in a adverse way ?

someone running gentoo posted in here earlier with the same issue.
precompiled or no, it's the same code. extreme optimizations could
possibly affect things adversely, but it would be inordinately
improbable for opptimization to fix a bug randomly.

Revision history for this message
Akshay Srinivasan (akshay.srinivasan) wrote :

I was experimenting with hdparm , and i found that there is a sleep mode
and a standby mode- which parks the read heads.So I issued the sleep
command in idle , and after a while , the temperature of the HDD went
down from 51 to 49 degrees.So I was wondering , may be that , whatever
is issuing the commands to the hard disk has these two modes mixed up.So
if it were possible to put the hard disk to sleep instead of standby , I
think most of our problems will be solved.

Revision history for this message
pointyhead (kraputnik) wrote :

 Luca Cerutti has a point, which may be relevant to finding the cause: Windows also has this problem in some cases, to wit, my Acer Travelmate 4010 laptop (Windows XP, with Hitachi IC25N060ATMR04 drive) has been getting increasingly more Load_Cycles per hour. The average over the last 250 hours was 25 per hour (Load_Cycle_Count/Power_On_Hours). So the problem extends beyond Ubuntu, and Linux. If my wife didn't need it for her job, I'd run a live Ubunto on it and see what happens under Linux. Seems like more multi-OS data on the same machine needs to be collected to get some controlled data.

Revision history for this message
maor (maors) wrote :

with 25 loads onloads the hard drive should survive for about three years which is much more reasonable then 7 months.
my machine at least has a much higher count per hour.
in that case its just a matter of noisy processes on Linux which keep waking up the hard drive and in that case there is no easy fix.
i will be much more interested with people with windows machine which do not have load unload cycles at
all.

btw: too bad no official Ubuntu developers are showing any interest in this. this bug is rated critical yet no work is done on him.

Revision history for this message
Debian God!! (debianlife) wrote :

@maor
The situation is more or less the same in windows!!!
Getting more load cycle count in xp than in ubuntu. Atleast there is the ugly fix for ubuntu. In win, you have to keep torrents or music running in the background!!!

Revision history for this message
maor (maors) wrote :

its weird the you say that the situation is the same in windows yet some people say windows does not park the heads at all.

if it is true it means that a windows machine hard drive would not last long before being destroyed by the high load/unload count.

there are two options:

1) your hard drive can handle all this loading/unloading so its enabled
2)some how results of your tests are screwed up. (this does not necessarily mean you are doing something wrong)

either way i dont know what to tell you. the only idea i have is contacting your hard drive manufacturer and asking him but all this.

imo this problem is not being fixed because no one is making a consistent effort to test the situation on both Linux and windows. if you want to put some effort in to it myself and other will try to offer suggestions.

maybe we can compile a list of people with models whose hard drives where trashed because if this problem to put some pressure on having someone who can actually commit code and is more experienced at solving this kind of problems.

Maor

Revision history for this message
Akshay Srinivasan (akshay.srinivasan) wrote : Re: [Bug 59695] Re: High frequency of load/unload cycles on some hard disks may shorten lifetime

maor wrote:
> its weird the you say that the situation is the same in windows yet some
> people say windows does not park the heads at all.
>
> if it is true it means that a windows machine hard drive would not last
> long before being destroyed by the high load/unload count.
>
> there are two options:
>
> 1) your hard drive can handle all this loading/unloading so its enabled
> 2)some how results of your tests are screwed up. (this does not necessarily mean you are doing something wrong)
>
> either way i dont know what to tell you. the only idea i have is
> contacting your hard drive manufacturer and asking him but all this.
>
> imo this problem is not being fixed because no one is making a
> consistent effort to test the situation on both Linux and windows. if
> you want to put some effort in to it myself and other will try to offer
> suggestions.
>
> maybe we can compile a list of people with models whose hard drives
> where trashed because if this problem to put some pressure on having
> someone who can actually commit code and is more experienced at solving
> this kind of problems.
>
> Maor
>
>
I installed Smartmontools for Windows , and surprising enough , when I
run smartctl , it says my Hard disk doesn't support SMART ! It says it
does , when I run it on Linux ....

Revision history for this message
Debian God!! (debianlife) wrote :

@maor

I have been testing this for three months now on 2 brand new Hpdv6602au lappies. Vista has done 30k load count, ubuntu on the other hand has done 23k cycles. Now you decide!!! Btw atleast you have the ugly fix here, in vista am running torrents or HD tune to compensate this. Now my only concern is the hdd temperature. :(

Revision history for this message
Akshay Srinivasan (akshay.srinivasan) wrote : Re: [Bug 59695] Re: High frequency of load/unload cycles on some hard disks may shorten lifetime

That's funny , I have a laptop of the same series , mine doesn't go
clicking all the time on Vista.As far as I know , mine has a WD Scorpio
HD , how about yours ?
On Sat, 2008-02-02 at 14:35 +0000, Debian God!! wrote:
> @maor
>
> I have been testing this for three months now on 2 brand new Hpdv6602au
> lappies. Vista has done 30k load count, ubuntu on the other hand has
> done 23k cycles. Now you decide!!! Btw atleast you have the ugly fix
> here, in vista am running torrents or HD tune to compensate this. Now my
> only concern is the hdd temperature. :(
>

Revision history for this message
Lorenzo Bettini (bettini) wrote :

By the way, the ugly fix, when running on batteries calls hdparm with 1 as parameter which means spindown set to 5 seconds... wouldn't it be better to use $SPINDOWN_TIME which by default is set to 12 (i.e., 12*5 seconds)? This var is set in /etc/default/acpi-support

Revision history for this message
Debian God!! (debianlife) wrote :

<quote><i>That's funny , I have a laptop of the same series , mine doesn't go
clicking all the time on Vista.As far as I know , mine has a WD Scorpio
HD , how about yours ?</quote></i>

Yes even mine is WD Scorpio, I will attach images of both vista & ubuntu in couple of days. I feel the count more or less depends on the applications we run. Though am not sure!!

Revision history for this message
CTenorman (ctenorman) wrote :

I've been doing some research on this issue, and the Debian fix (hdparm of 254 I believe) would seem to have a lot going for it. Google, in a massive study on hard drives, says

"One of our key findings has been the lack of a consistent pattern of higher failure rates for higher temperature drives or for those drives at higher utilization levels. Such correlations have been repeatedly highlighted by previous studies, but we are unable to confirm them by observing our population." (http://labs.google.com/papers/disk_failures.pdf)

So higher temperatures and longer running time may not really be affecting our drives hardly at all. Also, if the drives are forced to write very frequently because ext3, there's a very small chance our drives won't be engaged in the event of a fall. I doubt a user would blame Ubuntu if they dropped their laptop and their hard drive was damaged. They WOULD blame Ubuntu if it failed years before it would have under Windows.

So given that temperature and runtime don't seem to affect the drives significantly, and the drives are engaged nearly all the time, thus negating any benefit of parking, is there any reason not to run at 254 or 255 depending?

Revision history for this message
Akshay Srinivasan (akshay.srinivasan) wrote :

That might be true , but honestly my laptop gets too warm to keep it on
my lap when running linux.If Windows can somehow reduce Hard disk
temperature without parking heads madly , I think we can too.

On Mon, 2008-02-04 at 07:30 +0000, CTenorman wrote:
> I've been doing some research on this its essue, and the Debian fix (hdparm
> of 254 I believe) would seem to have a lot going for it. Google, in a
> massive study on hard drives, says
>
> "One of our key findings has been the lack of a consistent pattern of
> higher failure rates for higher temperature drives or for those drives
> at higher utilization levels. Such correlations have been repeatedly
> highlighted by previous studies, but we are unable to confirm them by
> observing our population."
> (http://labs.google.com/papers/disk_failures.pdf)
>
> So higher temperatures and longer running time may not really be
> affecting our drives hardly at all. Also, if the drives are forced to
> write very frequently because ext3, there's a very small chance our
> drives won't be engaged in the event of a fall. I doubt a user would
> blame Ubuntu if they dropped their laptop and their hard drive was
> damaged. They WOULD blame Ubuntu if it failed years before it would have
> under Windows.
>
> So given that temperature and runtime don't seem to affect the drives
> significantly, and the drives are engaged nearly all the time, thus
> negating any benefit of parking, is there any reason not to run at 254
> or 255 depending?
>

Revision history for this message
Baronek (baronek1) wrote :

My laptop was experiencing problem in this thread.
Now it is working quite better, hard drive can be idle for so long that it parks heads and so on - parking cycles still increses but I daresay at the sane levels - I've got 10k after half a 5 months of usage.
So what i did?

I've tried every trick that i can think of that could reduce hdd usage:
http://www.lesswatts.org/tips/disks.php - this was good starting place - I've used every trick there, took some of them to extreme.
I've inputed insane high values for everything, like thay say:
echo 1500 > /proc/sys/vm/dirty_writeback_centisecs
i did:
echo 150000 > /proc/sys/vm/dirty_writeback_centisecs

Other tricks (not only hard drive) are also worth trying.

I've checked logs, disabled acpi logging as this was cousing insane high amouts of logs (some kind of error or sth), set all logs NOT to be flushed.
I've disabled uneccessary services (cups for example - it is known to couse problems with hdd usage)
I've disabled or make happen not so often many services from cron (updatedb anyone? hate this). I do not start cron if on battery (with laptop mode)
Of course disks mounted with noatime, nodiratime.
I've enabled laptop mode with aggressive pwr mgmt (insane high amouts for acceptable data loss time for the example)
I am using B 128 on battery and 254 on ac. Hard drive spindown on battery is 30 seconds. If i do just web and IM hdd can be spined down for 10-15 minutes. (not parked, spined down)

I encourege all of you to try the same - tweak your system so no hard disk activity is going on, this is our problem, not head parking. On windows it just depend how much bloatware you have i guess.

Revision history for this message
Brian Ealdwine (eode) wrote : Re: [Bug 59695] Re: High frequency of load/unload cycles on some hard disks may shorten lifetime

I think we can, too -- but this is triage, as far as I'm concerned.

On Mon, 2008-02-04 at 11:57 +0000, Akshay Srinivasan wrote:
> That might be true , but honestly my laptop gets too warm to keep it on
> my lap when running linux.If Windows can somehow reduce Hard disk
> temperature without parking heads madly , I think we can too.
>
> On Mon, 2008-02-04 at 07:30 +0000, CTenorman wrote:
> > I've been doing some research on this its essue, and the Debian fix (hdparm
> > of 254 I believe) would seem to have a lot going for it. Google, in a
> > massive study on hard drives, says
> >
> > "One of our key findings has been the lack of a consistent pattern of
> > higher failure rates for higher temperature drives or for those drives
> > at higher utilization levels. Such correlations have been repeatedly
> > highlighted by previous studies, but we are unable to confirm them by
> > observing our population."
> > (http://labs.google.com/papers/disk_failures.pdf)
> >
> > So higher temperatures and longer running time may not really be
> > affecting our drives hardly at all. Also, if the drives are forced to
> > write very frequently because ext3, there's a very small chance our
> > drives won't be engaged in the event of a fall. I doubt a user would
> > blame Ubuntu if they dropped their laptop and their hard drive was
> > damaged. They WOULD blame Ubuntu if it failed years before it would have
> > under Windows.
> >
> > So given that temperature and runtime don't seem to affect the drives
> > significantly, and the drives are engaged nearly all the time, thus
> > negating any benefit of parking, is there any reason not to run at 254
> > or 255 depending?
> >
>

Revision history for this message
Brian Ealdwine (eode) wrote : Re: [Bug 59695] Re: High frequency of load/unload cycles on some hard disks may shorten lifetime

Apparently, laptop_mode causes issues for some people, though.

But, perhaps it would be doable to identify models that *do* have issues
with laptop_mode, and disable them? ..laptop_mode is what I'm using to
keep cool, these days.. Heads park, and stay parked for a reasonable
length of time.

On Mon, 2008-02-04 at 14:19 +0000, Baronek wrote:
> My laptop was experiencing problem in this thread.
> Now it is working quite better, hard drive can be idle for so long that it parks heads and so on - parking cycles still increses but I daresay at the sane levels - I've got 10k after half a 5 months of usage.
> So what i did?
>
> I've tried every trick that i can think of that could reduce hdd usage:
> http://www.lesswatts.org/tips/disks.php - this was good starting place - I've used every trick there, took some of them to extreme.
> I've inputed insane high values for everything, like thay say:
> echo 1500 > /proc/sys/vm/dirty_writeback_centisecs
> i did:
> echo 150000 > /proc/sys/vm/dirty_writeback_centisecs
>
> Other tricks (not only hard drive) are also worth trying.
>
> I've checked logs, disabled acpi logging as this was cousing insane high amouts of logs (some kind of error or sth), set all logs NOT to be flushed.
> I've disabled uneccessary services (cups for example - it is known to couse problems with hdd usage)
> I've disabled or make happen not so often many services from cron (updatedb anyone? hate this). I do not start cron if on battery (with laptop mode)
> Of course disks mounted with noatime, nodiratime.
> I've enabled laptop mode with aggressive pwr mgmt (insane high amouts for acceptable data loss time for the example)
> I am using B 128 on battery and 254 on ac. Hard drive spindown on battery is 30 seconds. If i do just web and IM hdd can be spined down for 10-15 minutes. (not parked, spined down)
>
> I encourege all of you to try the same - tweak your system so no hard
> disk activity is going on, this is our problem, not head parking. On
> windows it just depend how much bloatware you have i guess.
>

Revision history for this message
Brian Ealdwine (eode) wrote : Re: [Bug 59695] Re: High frequency of load/unload cycles on some hard disks may shorten lifetime

> Apparently, laptop_mode causes issues for some people, though.
>
> But, perhaps it would be doable to identify models that *do* have issues
> with laptop_mode, and disable them? [snip]

uh, that is, disable laptop_mode on them.. heh.

Revision history for this message
In , Eric (eric-redhat-bugs) wrote :

Bug confirmed un a Toshiba Satellite A210-FS3

I coded the following script. Do not use without checking if the HD temperature
is not going too high. Here is the script that you can activate through
/etc/rc.d/rc.local :

==============

#! /bin/bash
#Utility that checks whether the APM level is at 254 if not, reset it there.

SLEEP="120"

while [ true ] ; do

STATE=`hdparm -I /dev/sda | grep "Advan" | sed "s/.* \([0-9][0-9][0-9]*\).*/\1/"`
ASTATE=`echo ${STATE:0:3}`

     if [[ $ASTATE != "254" ]] ; then
           hdparm -B 254 /dev/sda
     fi

sleep ${SLEEP}s
done

==============

It is useful since each time it comes back from suspend or hibernate the value
is set back at 128 so having such a script reset it back to 254 which prevents
the Load_Cycle_Count problem as noted above.

Hope this help.

Eric

Revision history for this message
Akshay Srinivasan (akshay.srinivasan) wrote : Re: [Bug 59695] Re: High frequency of load/unload cycles on some hard disks may shorten lifetime

CTenorman :- I tried your suggestions , but sadly all of it went in
vain ...My hard disk actually goes to standby after ~15 seconds.I'm
starting to wonder if linux (kernel ?libata ?) can't control my hard
disk -or hard disk controller - effectively.I don't think the problem
behind this has to do anything with laptop mode or acpi per se ..

On Feb 5, 2008 3:00 AM, Brian Visel <email address hidden> wrote:
>
> > Apparently, laptop_mode causes issues for some people, though.
> >
> > But, perhaps it would be doable to identify models that *do* have issues
> > with laptop_mode, and disable them? [snip]
>
> uh, that is, disable laptop_mode on them.. heh.
>
>
> --
> High frequency of load/unload cycles on some hard disks may shorten lifetime
> https://bugs.launchpad.net/bugs/59695
> You received this bug notification because you are a direct subscriber
> of the bug.
>

Revision history for this message
Penguinnerd (ab-beadle) wrote :

I cannot believe the lack of attention that this bug is getting. I would try to fix it, but I'm still a noob. I used several different fixes, and my HD either overheats or the load cycle doesn't slow down. I think that if no progress in made by release 8.04, I'm either going to search for another distro or maybe go back to Windows, although I shudder at the thought.

I don't need my laptop ruined over a lack of effort by software developers. I just spent all my money on getting one with Ubuntu pre-installed from Dell. (I'm pretty much broke now!)

Revision history for this message
Daniel Bermudez G. (nergar) wrote : Re: [Bug 59695] Re: High frequency of load/unload cycles on some hard disks may shorten lifetime

I agree, the lack of a working fix is very disappointing but I really
don't think there is a lack of effort to solve it.

BTW your comment doesn't help at all, instead of making threats why
don't you try talking to Dell about your problem, after all you have a
warranty and they should give you a solution that works for you.

On Wed, 2008-02-06 at 22:07 +0000, Beads wrote:
> I cannot believe the lack of attention that this bug is getting. I would
> try to fix it, but I'm still a noob. I used several different fixes, and
> my HD either overheats or the load cycle doesn't slow down. I think that
> if no progress in made by release 8.04, I'm either going to search for
> another distro or maybe go back to Windows, although I shudder at the
> thought.
>
> I don't need my laptop ruined over a lack of effort by software
> developers. I just spent all my money on getting one with Ubuntu pre-
> installed from Dell. (I'm pretty much broke now!)
>

Revision history for this message
Penguinnerd (ab-beadle) wrote :

Sorry, it wasn't meant as a threat.

I do see plenty of work here on the issue, but I was under the impression that there was little work going into Canonical releasing 8.04 "pre-fixed" and that for a while it was dismissed as being due to the settings in the Bios or something.

Once again, I apologize for sounding that way. It's been a long day...

Revision history for this message
maor (maors) wrote :

beads:

if you have official support from dell then demand they would find a solution.
dell have Linux engineer who are suppose to certify Ubuntu on the hardware it runs.
there is also a mailing list for dell Linux.

someone here mentioned early that he had Linux support from dell and they replaced hes hard drive.

tell us how it went.

(btw canonical is not suppose to do everything we want it to do. this is a open source project and the real "heavy lifting" should come from the community)

Revision history for this message
CTenorman (ctenorman) wrote :

Hi Akshay,

I noticed that the "ugly" fix posted earlier didn't work too well for me either, perhaps my machine wasn't detecting whether it was plugged in or not. I simply put

     hdparm -B 254 /dev/sda

into the ugly fix file suggested, instead of the longer version which detects whether the machine is plugged in or not. I then did the install procedure as suggested, and It seemed to correct it for my machine. Does this command:

    sudo hdparm -B 254 /dev/sda

do anything for your machine at the command line? Have you tried changing 254 to 255? For some people that seems to help. Also, perhaps trying changing sda to hda, or depending on whether it's a second drive, change it to sdb or hdb.

If this doesn't work, I'd suggest going to the hard drive manufacturer's web site, and downloading their hard drive configuration tools. You can determine your hard drive type by going to System>Preferences>Hardware Information. My hard drive type is located under 82801HBM/HEM (ICH8M/ICH8M-E) SATA AHCI Controller. It's a couple of levels under that, but it shows up as a Fujitsu MHY2160B, and below the drive lists my partitions. Your mileage may vary, and you'll probably be looking for XXXXXX SATA XXXX Controller or XXXXXX HDA XXXXX Controller.

Usually the utility for configuring your hard drive available from the manufacturer is available as a bootable CD that you burn and boot to. You simply adjust the parameters from an screen there, following the directions they give. If hdparm doesn't get your machine to respond, this is what I would recommend.

My Dell also has an adjustment screen built right into my computer's bios, but it doesn't seem to do much, as the only options are bypass, quiet, and performance.

Let me know if using the hard drive manufacturer's utility to adjust hard drive parameters works. If not, we'll go from there.

Revision history for this message
CTenorman (ctenorman) wrote :

I've thought of a couple of other things we could try. First off, if EXT3 is writing more often than is optimal, could we have reports from people who use other file systems like JFS or XFS or ReiserFS? If changing the file system makes a big difference, it might be a solution. I've read that JFS, XFS and ReiserFS can have superior performance characteristics in many cases, and those who would be impacted by ext3 not being present (system admins who depend on ext3 for specific backup utilities, etc) would probably know enough to select the correct partition type for their unique work at installation.

Also, as a quick and easy test we could try installing powertop from the repositories. When the program boots up (sudo powertop), it gives a bunch of suggestions. We could simply try accepting each one of its suggestions (you can usually make the change by hitting a single key when prompted), and then monitor our hard drives for a few minutes to see how frequently they're loading. This might be a quick way for a number of us to identify what works for our drives without a lot of command line work, which some people might understandably shy away from.

These are just a few thoughts, let's see what comes of them! If this doesn't work, perhaps the best thing to do is contact the hard drive manufacturers. After all, they design the drives, and know what sort of behaviour the drives should be exhibiting. All the best,

Scott

Revision history for this message
Tzvetan Mikov (tmikov) wrote :

It is naive to expect that this can be fixed by the community. Problems of this kind can only be fixed by a coordinated entity with resources: someone that can purchase different hard drives, possibly laptops, and is able to put some pressure on the manufacturers for information, and to invest significant time in testing and development. Clearly Dell is in the best position to do this.

This bug entry has turned into a discussion forum, with the same things repeated over and over. I don't think there is anything useful to a developer aimed at fixing this beyond first few posts. The community has failed, so to speak, but as I said, this is not a problem amenable to a "community solution".

I strongly suspect that if somebody (a company) was seriously working on a fix, they wouldn't post here, possibly until the fix was ready.

My suggestion to everybody is to stop posting ideas (even if they are good, in actuality they are not helping) and evidence about their own system. It is useless !! Nobody is going to read all the messages to gather bits of evidence. Please, post only if you are a developer actively working on a fix, or if a developer asks for specific tests to be done by somebody with the problem (admittedly the latter is a very long shot).

Revision history for this message
Akshay Srinivasan (akshay.srinivasan) wrote : Re: [Bug 59695] Re: High frequency of load/unload cycles on some hard disks may shorten lifetime

Tzvetan Mikov wrote:
> It is naive to expect that this can be fixed by the community. Problems
> of this kind can only be fixed by a coordinated entity with resources:
> someone that can purchase different hard drives, possibly laptops, and
> is able to put some pressure on the manufacturers for information, and
> to invest significant time in testing and development. Clearly Dell is
> in the best position to do this.
>
> This bug entry has turned into a discussion forum, with the same things
> repeated over and over. I don't think there is anything useful to a
> developer aimed at fixing this beyond first few posts. The community has
> failed, so to speak, but as I said, this is not a problem amenable to a
> "community solution".
>
> I strongly suspect that if somebody (a company) was seriously working on
> a fix, they wouldn't post here, possibly until the fix was ready.
>
> My suggestion to everybody is to stop posting ideas (even if they are
> good, in actuality they are not helping) and evidence about their own
> system. It is useless !! Nobody is going to read all the messages to
> gather bits of evidence. Please, post only if you are a developer
> actively working on a fix, or if a developer asks for specific tests to
> be done by somebody with the problem (admittedly the latter is a very
> long shot).
>
>
I got this DiskCheckup tool for Windows , which reads SMART data from
the Hard Disk.After a while , I was quite surprised to find the Parking
rate to be at about 2-3 per minute.I don't think Windows does anything
to aleter the settings either - or maybe , the controls are all messed up ?

Revision history for this message
Akshay Srinivasan (akshay.srinivasan) wrote :

I was listening to my Hard drive , when running Ubuntu.I could hear the disk heads parking , but the disk itself doesn't spin down.It spins down -standby mode- when one runs 'hdparm -y /dev/sda'.It stayed in standby for quite a long time.Doesn't this seem a little odd ?I thought it was spinning down when the disk heads parked .

Revision history for this message
Akshay Srinivasan (akshay.srinivasan) wrote : High frequency of load/unload cycles on some hard disks may shorten lifetime

So , the hard disk doesn't exactly go into suspend when the disk head is
parked, so the kernel doesn't get to know that the disk head is
parked(because standby=>parking) - it interprets this as a sign that the
hard disk is in Active/Idle mode.So it doesn't bother stopping data from
being written to the disk - this will inevitably cause the head to
unpark from the ramp.What do you guys think of this ?I think the problem
is associated with the way in which the standby command is issued (by
the kernel?).My disk never went to standby on laptop-mode , just a bunch
of head parkings.
 .I used hdparm to find the mode of the HD.Hdparm doesn't wake up the
disk from standby by state -in contrast to smartctl.

Revision history for this message
Akshay Srinivasan (akshay.srinivasan) wrote : Re: [Bug 59695] Re: High frequency of load/unload cycles on some hard disks may shorten lifetime

Another interesting observation:
 My hard disk -WD Scorpio - has only three power modes
1-127 Spin down for idle time of ~2 secs + Park heads
128-253 Keep parking heads , without spinning down
254/255 Don't do anything
 Neither Hdparm nor the kernel can control the spin down time of my hard
disk , that is the problem.If I could do that , with -B 1 , the problem
with my hard disk will be solved , could anyone verify this on their
hard disks?
On Sat, 2008-02-09 at 08:43 +0000, Akshay Srinivasan wrote:
> I was listening to my Hard drive , when running Ubuntu.I could hear the
> disk heads parking , but the disk itself doesn't spin down.It spins down
> -standby mode- when one runs 'hdparm -y /dev/sda'.It stayed in standby
> for quite a long time.Doesn't this seem a little odd ?I thought it was
> spinning down when the disk heads parked .
>

Revision history for this message
Akshay Srinivasan (akshay.srinivasan) wrote :

I confirm Ctenor's trick of inserting high values in the
dirty_writeback_centisecs file.From my empiral calculations , I found
the value was read as millisecs instead of centisecs.

On Sat, 2008-02-09 at 08:43 +0000, Akshay Srinivasan wrote:
> I was listening to my Hard drive , when running Ubuntu.I could hear the
> disk heads parking , but the disk itself doesn't spin down.It spins down
> -standby mode- when one runs 'hdparm -y /dev/sda'.It stayed in standby
> for quite a long time.Doesn't this seem a little odd ?I thought it was
> spinning down when the disk heads parked .
>

Revision history for this message
Bart Samwel (bart-samwel) wrote : Re: [Bug 59695] High frequency of load/unload cycles on some hard disks may shorten lifetime

Akshay Srinivasan wrote:
> So , the hard disk doesn't exactly go into suspend when the disk head is
> parked, so the kernel doesn't get to know that the disk head is
> parked(because standby=>parking) - it interprets this as a sign that the
> hard disk is in Active/Idle mode.So it doesn't bother stopping data from
> being written to the disk - this will inevitably cause the head to
> unpark from the ramp.What do you guys think of this ?I think the problem
> is associated with the way in which the standby command is issued (by
> the kernel?).My disk never went to standby on laptop-mode , just a bunch
> of head parkings.

But that's not how laptop mode works. Laptop mode simply assumes that
the drive has been configured to "do the right thing" during idle
periods, and then it simply holds off I/O as long as possible, and then
tries to cram in as much I/O as possible at a time when there is some
I/O that cannot be postponed. The kernel never actually checks the
drive's power state, just like it doesn't actively spin it dow -- it's
using only the assumption "if I hold off I/O for longer periods, the
drive will somehow use this to save power".

Cheers,
Bart

Revision history for this message
Jakob Unterwurzacher (jakobunt) wrote : The Debian Fix

This is the official Debian fix, extracted from the latest acpi-support Debian package: http://ftp.at.debian.org/debian/pool/main/a/acpi-support/acpi-support_0.103-5_i386.deb .

The attached file, 90-hdparm.sh goes to the following two directories:
/etc/acpi/start.d
/etc/acpi/resume.d

That's all.

Dear Ubuntu package maintainer, take it and use it.

Revision history for this message
Jakob Unterwurzacher (jakobunt) wrote : The Debian Fix (correction + debdiff)

The file 90-hdparm.sh (attached above, comment #375) goes to the following four directories:
/etc/acpi/ac.d
/etc/acpi/battery.d
/etc/acpi/resume.d
/etc/acpi/start.d

Attached here is a debdiff between Ubuntu's and Debian's acpi-support package, created with:
debdiff acpi-support_0.103.dsc acpi-support_0.103-5.dsc ,
with everything but the 90-hdparm.sh stuff removed.

Revision history for this message
SirLancelot (lukaszgraczyk) wrote : Re: [Bug 59695] The Debian Fix (correction + debdiff)

How to install this Fix under Ubuntu 7.10? Debian package give me this kind
of error messages:

Error: Dependency is not satisfable: acpi-support-base

After instalation:

acpi-support-base_0.103-5_all.deb

From:

http://packages.debian.org/lenny/all/acpi-support-base/download

Next Error was:

Error: Dependency is not satisfable: libc6

After instalation:

libc6_2.7-5ubuntu2_i386.deb

From:

http://packages.ubuntu.com/cgi-bin/download.pl?arch=i386&file=pool%2Fmain%2Fg%2Fglibc%2Flibc6_2.7-5ubuntu2_i386.deb&md5sum=6086195ebf404a874e2d721d730fa28a&arch=i386&type=main

Next Error message is:

Error: Dependency is not satisfable: x11-xserver-utils

This package generates conflict with so many packages in Ubuntu 7.10 that I
just have to back to Ugly FIX by Ubuntu Deamon.

How to install this Debian FIX? When Ubuntu will create official Ubuntu
Package with this FIX?

2008/2/16, Jakob Unterwurzacher <email address hidden>:
>
> The file 90-hdparm.sh (attached above, comment #375) goes to the following
> four directories:
> /etc/acpi/ac.d
> /etc/acpi/battery.d
> /etc/acpi/resume.d
> /etc/acpi/start.d
>
> Attached here is a debdiff between Ubuntu's and Debian's acpi-support
> package, created with:
> debdiff acpi-support_0.103.dsc acpi-support_0.103-5.dsc ,
> with everything but the 90-hdparm.sh stuff removed.
>
> ** Attachment added: "debdiff of Debian's 90-hdparm.sh fix"
> http://launchpadlibrarian.net/12024340/debian-hdparm-fix.debdiff
>
> --
> High frequency of load/unload cycles on some hard disks may shorten
> lifetime
> https://bugs.launchpad.net/bugs/59695
> You received this bug notification because you are a direct subscriber
> of the bug.
>

--

Pozdrawiam Serdecznie.

Łukasz Graczyk

Revision history for this message
Jakob Unterwurzacher (jakobunt) wrote : Applying the Debian fix manually

If you want to use the Debian fix now, *DO NOT* install the Debian acpi-support package (dowloaded from somewhere.debian.org). This won't work or - worse - will break your system.

Instead, download this file,
http://launchpadlibrarian.net/12024037/90-hdparm.sh (from comment #375),

and copy it to these four directories:
/etc/acpi/ac.d
/etc/acpi/battery.d
/etc/acpi/resume.d
/etc/acpi/start.d

Revision history for this message
SirLancelot (lukaszgraczyk) wrote : Re: [Bug 59695] Applying the Debian fix manually

Thanks! I have removed "acpi-support-base" and the Ugly FIX by Ubuntu_Daemon
from my Ubuntu. I have installed "90-hdparm.sh" by:

sudo install 90-hdparm.sh /etc/acpi/resume.d/
> sudo install 90-hdparm.sh /etc/acpi/start.d/
> sudo install 90-hdparm.sh /etc/acpi/ac.d/
> sudo install 90-hdparm.sh /etc/acpi/battery.d/
>
> Is this FIX is OFFICIAL Canonical FIX for this bug?

Anodther question is... Is it correct that I have files in:

/etc/acpi/resume.d

Like:

 90-thinkpad-unstandby-led.sh

 90-xscreensaver.sh

Those files have same "90" number at the beginning of the file name. Is it
correct for the system functionality?

2008/2/16, Jakob Unterwurzacher <email address hidden>:
>
> If you want to use the Debian fix now, *DO NOT* install the Debian acpi-
> support package (dowloaded from somewhere.debian.org). This won't work
> or - worse - will break your system.
>
> Instead, download this file,
> http://launchpadlibrarian.net/12024037/90-hdparm.sh (from comment #375),
>
> and copy it to these four directories:
> /etc/acpi/ac.d
> /etc/acpi/battery.d
> /etc/acpi/resume.d
> /etc/acpi/start.d
>
> --
> High frequency of load/unload cycles on some hard disks may shorten
> lifetime
> https://bugs.launchpad.net/bugs/59695
> You received this bug notification because you are a direct subscriber
> of the bug.
>

--

Pozdrawiam Serdecznie.

Łukasz Graczyk

Revision history for this message
sharninder (sharninder) wrote :

Anyone knows if Debian's fix was ported over for Ubuntu 8.04 ?

Revision history for this message
Jakob Unterwurzacher (jakobunt) wrote :

> sudo install 90-hdparm.sh /etc/acpi/resume.d/
Should be ok.

> Is this FIX is OFFICIAL Canonical FIX for this bug?
The Debian fix is NOT a official fix from Canonical or Ubuntu. It's what Debian did about this problem.

> Those files have same "90" number at the beginning of the file name. Is it correct for the system functionality?
Yes. That's ok.

> Anyone knows if Debian's fix was ported over for Ubuntu 8.04 ?
It is not ported over (yet?).
See http://packages.ubuntu.com/cgi-bin/search_contents.pl?searchmode=filelist&word=acpi-support&version=hardy&arch=i386&page=1&number=all -
no 90-hdparm.sh ...

Revision history for this message
Heikki Keränen (heikki-a-keranen) wrote :

I can confirm this with HP nc8430 laptop, 250 GB Samsung HDD and Ubuntu Hoary 8.04 Alpha 4. So not fixed yet. Load_Cycle_Count increases about every 10 seconds or so.

Revision history for this message
Jakob Unterwurzacher (jakobunt) wrote : Debian Fix: Possible small regression

From http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=457386 :

"the fix for the load cycling error gets applied to optical drives as well
as hard disks. this leads to somewhat scary kernel log errors such as

  Dec 21 21:56:48 kernel: hdb: drive_cmd: status=0x51 { DriveReady
  SeekComplete Error }"

Problem:
hdparm -B 254 is applied to /dev/hdX and /dev/sdX.
Some of these may be optical drives which don't support setting power management levels.

Affected releases:
This probably does NOT affect Gutsy ( DVD-drive here on Gutsy is /dev/scd0 - can one rely that optical drives will be /dev/scdX ? ).
I don't know about older relases. (Dapper, Edgy, Feisty users: What is your DVD, CD-ROM drive called?)

Impact:
"scary kernel log errors". Nothing else for now.

Revision history for this message
Mark Baas (mark-baas123) wrote :

Does it also affect External USB Harddisks? Mine does not support smartctl so i cannot check. I do hear clicks, but those are also present when not connected to laptop.

Revision history for this message
sibidiba (sibidiba) wrote :

This bug is more than five months old, and it is still not fixed neither in Gutsy nor in Hardy?!(?!?!)

I find this horrific, especially because there are multiple well known and trivial fixes, not just in this thread.

I would like to point out, that even applying the most trivial fix of disabling the APM power saving (-B 255) on every system by default is a magnitude better than the current state.
I doubt if any power saving could be achieved by this feature, because on most system something causes a spin-up of the disk either way (syslog, atime writes, journaling etc.).
And this feature has also nothing to do with shock-protection of the disks, that is the job of HDAPS and similar systems.
And even when it would save power, losing 1% of battery power is not so bad compared to loosing half the lifetime of a HDD.

Could someone please push any of the fixes upstream?

Revision history for this message
Brian Ealdwine (eode) wrote : Re: [Bug 59695] Re: High frequency of load/unload cycles on some hard disks may shorten lifetime

This bug has been around for over two years. It has been reported for
over one year.

It's incredibly demotivating. I'm just disappointed with Ubuntu's
organization at this point. There doesn't seem to be any way to
escalate this. It's laughable, and it's embarrassing, and I cannot and
do not recommend Ubuntu anymore. Not only that, I can't, even if this
bug gets fixed, because of the larger issue with structured
communication in the Ubuntu community. There's an obvious breakdown
here, not merely in the bug itself, but in the system used for handling
bugs. Is there a way, in the system that's provided, to change the
system sufficiently to fix that breakdown? What exactly is the problem,
anyways, and how is it fixed? I guess this is a topic that should be
continued elsewhere, though..

> This bug is more than five months old, and it is still not fixed neither
> in Gutsy nor in Hardy?!(?!?!)
>
> I find this horrific, especially because there are multiple well known
> and trivial fixes, not just in this thread.
>
> I would like to point out, that even applying the most trivial fix of disabling the APM power saving (-B 255) on every system by default is a magnitude better than the current state.
> I doubt if any power saving could be achieved by this feature, because on most system something causes a spin-up of the disk either way (syslog, atime writes, journaling etc.).
> And this feature has also nothing to do with shock-protection of the disks, that is the job of HDAPS and similar systems.
> And even when it would save power, losing 1% of battery power is not so bad compared to loosing half the lifetime of a HDD.
>
> Could someone please push any of the fixes upstream?

Changed in acpi-support:
status: Confirmed → Triaged
assignee: nobody → ubuntu-kernel-acpi
Revision history for this message
Przemek K. (azrael) wrote :

Hardy uses pm-utils instead of acpi-support, so I'm not sure if this bug appears in Hardy (it depends on default pm-utils configuration). I don't have hardy yet so someone should check if this bug is present there.

Revision history for this message
Christian Schürer-Waldheim (quincunx) wrote :

Yes, I can confirm that this severe problem is still present in hardy. As far as I know hardy is not using pm-utils yet. It's the plan to use pm-utils, but currently acpi-support is still the default.

Someone mentioned that probably the kernel calls for idling the hard drive where mixed up - has this possibility been investigated further? The first ubuntu on my current DELL notebook computer was an alpha release of feisty. Apparently, the problem first showed up in gutsy, so a correlation of this bug to the kernel used seems possible to me.

Revision history for this message
Tzvetan Mikov (tmikov) wrote : Re: [Bug 59695] Re: High frequency of load/unload cycles on some hard disks may shorten lifetime

On Sun, Feb 24, 2008 at 3:03 PM, Brian Visel wrote:

> This bug has been around for over two years. It has been reported for
> over one year.
>
> It's incredibly demotivating. I'm just disappointed with Ubuntu's
> organization at this point. There doesn't seem to be any way to
> escalate this. It's laughable, and it's embarrassing, and I cannot and
> do not recommend Ubuntu anymore.

The big question is, would it have made a difference if you had a paid
support contract with Canonical ? If not, why would people pay for it ?

Revision history for this message
houstonbofh (leesharp) wrote : Re: [Bug 59695] Re: High frequency of load/unload cycles on some hard disks may shorten lifetime

Brian Visel wrote:
> This bug has been around for over two years. It has been reported for
> over one year.
>
> It's incredibly demotivating. I'm just disappointed with Ubuntu's
> organization at this point.

This kind of thing amazes me. This bug is present to some extent in all
operating systems. There are several Linux fixes out, and all of them
have issues... There is no Vista fix I am aware of. There is not even
discussion of this in MAC forums, but it could be because Apple has not
speced any of the problem drives yet. However, this is all Ubuntu's
fault...

There is an old quote attributed to Ronald Reagan, Harry S. Truman, and
even Machiavelli... "It's amazing what you can accomplish when you don't
care who gets the credit." The converse of that is that you get nothing
done if you waste all your time assigning blame.

    Lee

Revision history for this message
Jakob Unterwurzacher (jakobunt) wrote :

The fix is not that easy (i thought it was when i posted the Debian fix, but it isn't, as that causes trouble somewhere else).

Situation now:
Use laptop-mode to control your hd power management if you think your hard drive will die otherwise.
This option has always existed. Use it!

Hint: sudo gedit /etc/laptop-mode/laptop-mode.conf

Revision history for this message
Martin Pitt (pitti) wrote : Re: [Bug 59695] Re: High frequency of load/unload cycles on some hard disks may shorten lifetime

Brian Visel [2008-02-24 23:03 -0000]:
> It's incredibly demotivating. I'm just disappointed with Ubuntu's
> organization at this point. There doesn't seem to be any way to
> escalate this.

We are aware of this report for as long as it exists. We just
explained over and over again why we won't/can't fix it, and the
misunderstandings around it. So yes, it seems to be a communication
problem, but maybe in a different direction than you suggest. :-)

Revision history for this message
xzirrow (xzirrow) wrote :

hi all ! I little bit frustrated with discussion in this thread , cause many poeple talking about different hdparm -B params and the ways to insert it .
IMHO ,of cause it's depends of such params , but I think this problem is much deeper . I can say i've expirenced may be hundered of this . And always there
HDD reacts in different way . I can share that even how your /etc/fstab look like can impact on HDD count and temp . First off all i've purged acpid and acpi-support and started to control this manually ?to see what i really need .But everything i've got - it seems that HDD delepends from soft i used . For example Thunderbird stopped the count ticking in some cases.deluge also. But without acpi it still ticking, i've reinstalled acpid and dpkg --configure acpid . And it WORKs ! For some weeks , it was no ticking and no hdd overheating . After that i've repartitioned mу HDD and changed fstab . And it started again . ok , and i've done the same trick . But afterthat it won't work.I was dissapointed .
Some days ago, i've installed wine , wich in procces of installation --reconfured acpid again (it was some log about it) . After that HDD strated to overheat and ticking both :( terrible ! Now i've purged acpid and acpi-support again . And now it works . Normal ticking - several in hour . and temp 41-43 C in normal and compete overheat like 49 C in heavy applications like vmware.

Is in't that strange ? If somebody is interested i can tell everything what i've met , may be it will can somehow .

Revision history for this message
Akshay Srinivasan (akshay.srinivasan) wrote :

HDD does act in a strange way to software changes , and sadly its hard
to reproduce effects.I think we'd all love to know about the stuff you
encountered.

Revision history for this message
Tomasz Witko (witko) wrote :

Tomasz_Witko writes:

 I have a Dell XPS 1530 and am still in the install planning stage.

 Looking over this bug it might be possible to tweek a laptop and hard drive hardware listing for affected hard drives. In affect a bugged bug hardware list. This could possibly help structure the handling of this bug and help with fixes for specific models. Also a listing on the hardware compatibility page could help address this problem and help distribute fixes pertaining to makes and models.

 Though one bug it spans a lot of subtopics as in models etc.

Revision history for this message
Andres Mujica (andres.mujica) wrote :

Please check https://wiki.ubuntu.com/DanielHahler/Bug59695 for a more concise discussion about this bug, with links to other references.

Probably it's a good idea to add to this wiki the list of hard drives affected.

Revision history for this message
Seth (seedifferently) wrote :

Beware: I just "dist-upgraded" from gutsy to hardy and the listed workarounds are no longer solving this issue for me. I have to set "sudo hdparm -B 255 /dev/sda" manually each time I resume the computer, otherwise I am getting 5-10 "clicks" per minute.

Revision history for this message
Denis (link011) wrote :

Workarounds stopped helping me when i changed power manager to Kpowersave....
Also it would be good to see state of the bug. Not "confirmed" or messages in blog, but real state:
what is done, what should be done, or any reasons why it is not fixed yet.

Revision history for this message
Martin Pitt (pitti) wrote :

Unsubscribing Ubuntu SRU team. This is not a valid SRU request at all. Please see https://wiki.ubuntu.com/StableReleaseUpdates

Revision history for this message
sibidiba (sibidiba) wrote :

I still can not understand why not to apply Bart Samwel's (https://launchpad.net/ubuntu/+source/acpi-support/+bug/59695/comments/229) solution. Debian did.

It is simple, and more important: it works. Even when the reasons and requirements for this bug are not fully understood, could somebody point out it's drawbacks?

If Hardy ships in the current state, we will see an LTS distro that is killing the hard drives of it's users.

Revision history for this message
Steve (st3v3) wrote :

I'm inclined to agree, though it's worth noting that (AFAIK, https://answers.launchpad.net/ubuntu/+source/pm-utils/+question/23292) the plan for Hardy is to move to pm-utils, so rather than /etc/acpi/{battery,start,resume,ac}.d, the script would need to go in /usr/lib/pm-utils/{power,sleep}.d.

I'm using this at the moment to control a Seagate Momentus disk in my Thinkpad X61s, and it works just great. Unfortunately the Load_Cycle_Count got to 240,000 before this issue came to light :'-(

Revision history for this message
Pacho Ramos (pacho) wrote :

Seems that laptop-mode-tools should fix this as read in Changelog:
-Set HD power management values to 254 instead of 255. Some hard drives go into "no power management" mode only on 254, while 255 yields some kind of default that you don't want.

http://www.samwel.tk/laptop_mode/changelog

Revision history for this message
sibidiba (sibidiba) wrote :

Changes in laptop-mode can not fix this, because laptop-mode is disabled by default.

Even if enabled, you still have to explicitly set CONTROL_HD_POWERMGMT=1 in the configuration of laptop-mode.

BTW the reason why laptop-mode is fixing this problem is, that if the latter option is set, it calls hdparm -B with sane parameters. So it does the same as suggested before as a fix.
(But laptop-mode can not be enabled by default, because it is for laptops and because some models just freeze with it.)

Anyway, I blogged the solutions, I hope this gets resolved before Hardy... http://www.gablog.eu/online/node/53

Changed in laptop-mode-tools:
status: In Progress → Invalid
Changed in laptop-mode-tools:
status: Unknown → Confirmed
Revision history for this message
Lukas Lipka (lukaslipka) wrote :

My 6 months old notebook's hard-drive died today with somewhere around 65 load cycles per hour. Thanks for the high priority of fixing this.

Revision history for this message
Martin Wilson (martinmwilson) wrote :

    I also had a notebook hard drive just die. It was a Samsung in a Dell XPS M1330. I am not saying that because the hard drive died, and I have taken interest in this bug, that this bug is the reason. However I did have smartctl report high load cycle counts (although I know this is not alway accurate). I can also confirm that the hard drive was ONLY used under Ubuntu for the 4.5 month period it was alive (except for the 1 week with the preinstalled Vista). And it was never dropped etc. And it also made a loud click 2-3 times a minute that it would not make when using the preinstalled Vista before it was removed. So, while this is all just circumstantial evidence, take it or leave it as raw data.

    By the way, I would just like to mention one thing. I have been subscribed to this bug for months (in fact I was subscribed to other bugs that this duplicated to hush some of the troubleshooting going on in bug reports). One of the arguments we see is the balance between protecting the hard drive and reducing life from power cycling. Take in to account the two highest probability hard drive killers from this argument:

1. The user drops the computer but the head was not parked and the platters are damaged.
2. The user gradually starts experiencing filesystem issues from a hard drive reaching the end of it's life.

    Now, considering both options, which one is primarily caused by the OS? The second much more than the first. While the OS _MAY_ have helped with the first situation, it is not definite and many users are not aware that the OS will even attempt to park the head when not in use. In fact, most users don't even know what a hard drive head is, let alone a hard drive.
    I am aware that the second situation, which in my hypothetical is mostly caused by the OS, allows for the user to make backups before serious failure as opposed to the first situation. But in this hypothetical, let's say a person suddenly has a few files get corrupted, or perhaps even experiences some errors in day to day operation. Is this user going to get their external hard drive and run dd_rescue? Most likely not, I know my parents don't even know what dd is.
    My personal opinion, which I know does not amount to much in the scheme of things :), is that as a user-friendly distribution we should help pioneer ways to protect the less-technically-inclined user first and still leave all the options there for people who want to dig. And I think that for this bug, the primary way to do this is to stop parking the head so much by default.

Revision history for this message
Akshay Srinivasan (akshay.srinivasan) wrote :

I still wonder if its Ubuntu -Linux in general - is the cause of this
problem.On my laptop , after removing unwanted apps Windows parks heads
as frequently as linux.This takes some time to occur after startup - may
be because of all that disk i/o.Can anyone confirm this ?There is a tool
called Diskcheckup which you might want to use.

Revision history for this message
Andres Mujica (andres.mujica) wrote :

I can confirm this too, the problem is not related to linux exclusively. we've
got some vostro 1500 one of them with vista and the rest with ubuntu. all of
them are affected by this bug.

According with our research the problem lies mostly on the Disk Drive
firmware's If you check the wiki page about this bug you'll find some hdd
firmware upgrades for lenovo laptops that addresses the problem.

Also if you ask Dell for warranty replacement they'll give it to you

El Lunes 17 Marzo 2008 01:27, Akshay Srinivasan escribió:
> I still wonder if its Ubuntu -Linux in general - is the cause of this
> problem.On my laptop , after removing unwanted apps Windows parks heads
> as frequently as linux.This takes some time to occur after startup - may
> be because of all that disk i/o.Can anyone confirm this ?There is a tool
> called Diskcheckup which you might want to use.

--
Andrés Mauricio Mujica Zalamea
Consultor Linux RHCE #804005093216652
SEAQ SERVICIOS CIA LTDA
Tel: (57) 1 6559800
Fax: (57) 1 6559802
www.seaq.com.co

Revision history for this message
Dan Gilliam (geocritter) wrote :

I can't say the same. I get high load counts in Ubuntu Gutsy on my Toshiba with a Seagate Momentus. On a fresh install, either plugged in or unplugged (I never saw any change in the count) I'm getting about one every 10 seconds to 1 minute. Under Windows XP, I'm seeing like 2 to 4 per hour; none if there's no activity.

It's not all Ubuntu, of course. All the other distros are showing the same as I've hopped around a bit. I tried applying the various fixes that I've found, but I'm not seeing any difference in the increased load counts. Which is frustrating, because windows is obviously doing SOMETHING to control it. Question is, what, and how, to impliment this.

I don't know if pm-utils will be a different change or not. I haven't tried it, and am not sure how. If somebody wants me to try it, I will, just tell me what to do.

Revision history for this message
Akshay Srinivasan (akshay.srinivasan) wrote : Re: [Bug 59695] Re: High frequency of load/unload cycles on some hard disks may shorten lifetime

I'm not sure about this , but could there be something wrong with the
SATA controller onboard the chipset ?
>

Revision history for this message
houstonbofh (leesharp) wrote : Re: [Bug 59695] Re: High frequency of load/unload cycles on some hard disks may shorten lifetime

Dan Gilliam wrote:

> It's not all Ubuntu, of course. All the other distros are showing the
> same as I've hopped around a bit. I tried applying the various fixes
> that I've found, but I'm not seeing any difference in the increased load
> counts. Which is frustrating, because windows is obviously doing
> SOMETHING to control it. Question is, what, and how, to impliment this.

I have a laptop with this problem, but I didn't notice... Why? Bit
torrent and seeding distributions is an excellent patch! :) If you
never leave the hard drive alone, it never parks. If you FINALLY finish
loading the OS, and never wake up the hard drive, it never unparks. I
think the Ubuntu problem is because we finish loading, so it can park,
but wake every few seconds for random reasons and unpark. Vista, on the
other hand, will be an hour finishing booting...

Revision history for this message
Jim Qode (jimqode) wrote :

I can confirm this bug on Dell XPS M1330 with Hardy Heron Alpha 6. My harddrive is Western Digital WDC WD1200BEVS-75UST0. hdparm -B 255 stops clicking until next stanby/wakeup.

Revision history for this message
Mark Baas (mark-baas123) wrote :

I recommend using the following page for hardy:
http://en.opensuse.org/Disk_Power_Management

It does not turn off power management, but in turn it will put it on 254 when on power and higher (click every 20 minutes) when on battery.
 Here are my script for /etc/pm/config.d

Revision history for this message
Mark Baas (mark-baas123) wrote :

And here the script for /etc/pm/power.d

Be warned... to have installed both scripts.

Revision history for this message
Jim Qode (jimqode) wrote :

I already had written a little script for that does the same thing but the one you pointed to is more generalized and can be used for >1 drives so I started using it now. Works like expected now. I don't use -B 255 for ac power though. Because the disk overheats then.

Thank you for the pointers. I think this really should be in the release.

Revision history for this message
Akshay Srinivasan (akshay.srinivasan) wrote : Re: [Bug 59695] Re: High frequency of load/unload cycles on some hard disks may shorten lifetime

Isn't that workaround meant for people with pm-utils ?The folder /etc/pm
does not exist by default.
Anyway , I executed hdparm with -B 200 and -S 242 , and well , my hard
drive just doesn't respond to them.It keeps working as it would on -B 128.
I suspect the firmware to my Hard disk is buggy.Can you send more
details of your Hard disks ?

Revision history for this message
Mark Baas (mark-baas123) wrote :

I am talking about hardy, not gutsy. I agree never use 255, i adapted the script of suse a little. I hope ubuntu just puts these scripts, i think it would be a valid bug fix.

Changed in laptop-mode-tools:
status: Confirmed → In Progress
Revision history for this message
Mark Baas (mark-baas123) wrote :

I have to confirm that this bug also affect winxp. I recently installed that on another partition to play a specific game. This game was installed on a external harddrive, so this means that the normal laptop drive was never accessed. Later i checked the cycles in ubuntu and saw that in like 2 hours 100 spindows. So i hope those morons that have put ubuntu in dark light will shut up now. It is the manufacturer's fault.

Revision history for this message
Akshay Srinivasan (akshay.srinivasan) wrote :

I could here the disk head parking , about 8s after GRUB was loaded.This
really seems to be a problem with the firmware of the Harddisks.
Also I'd like to mention , that there is a difference between disk head
parking and spin down , from what I could hear - from my hard disk - the
disk head might be parked even when the disk is not spinning down - or
up.There is another Parameter , to measure the number of spin downs -
Start_Stop_Count - this one has a minimum threshold of ~30000 before
failure.

Revision history for this message
Heikki Keränen (heikki-a-keranen) wrote :

I just installed Ubuntu Hardy 8.04 beta. To my surprise the HD does not click anymore and the Load_Cycle_Count has not increased in hours. The previous alpha I tried with the same hardware was clicking like crazy, approximately once per 10 seconds. I have not made a single try to fix the problem after Hardy beta installation. So something has apparently changed for the better. It would be nice to know the details what has changed.

Revision history for this message
Dan Gilliam (geocritter) wrote :

I just installed Hardy beta, and still had the same problem on my Toshiba. I had to go in and do the "-B 254 fix". And for those debating the "Windows does it too" question, I respectfully enter that mine does NOT do it under XP. Only under linux. Windows is obviously setting it correctly, linux still isn't (unless the debian fix does something I don't know about yet). I'm also curious as to the pm-utils switchover...I wonder if that whole thing might fix it.

Revision history for this message
Christian Wolf (christianwolf) wrote :

Dan,

does disabling CD drive polling help on your machine?

Do you see any improvement from
sudo hal-disable-polling --device /dev/cdrom ?

(Side effect: does not open Nautilus window for a CD when inserted, turn it back on by deleting the created file in /etc/hal/fdi/information/prefrences.fdi )

Make sure that you compare your system while no applications are running. On my system, the HD kept quiet once the heads were parked; only disc access lead to new parking and click.

This is, by the way, a hint that powertop gave me. Maybe HAL or a bug in HAL is waking up the HD s often.

Revision history for this message
pan Proteus (bartjablo) wrote :

I have been using "ugly workaround" (-B 254) since Hardy Alpha5. Recently - with Beta, I tried hibernation on my laptop. After resuming disk head was ticking again and the Load_Cycle_Count started increasing. I checked and /etc/acpi/resume.d/<script> was still there along with others... but apparently had not been read during resume. Looks like the bug is still there in Hardy beta.

Revision history for this message
Christian Schürer-Waldheim (quincunx) wrote :

Ubuntu is currently switching to pm-utils, so you have to put your script (probably you have to customize it first) into the directories of pm-utils. I can send you the correct paths later, I'm not at my ubuntu computer right now.

Revision history for this message
gunsarebad (rjonesmoo) wrote :

I'm mostly confused, and a little concerned. This information may me useful, but I am probably doing something rather ignorant. It says my Load_Cycle_Count is 64424510589, with 665 for Power_On_Hours. I'm on a Dell xps m1330 that I bought in January, with a 160 GB hard drive, FUJITSU MHW2160BJ FFS G2. I'm sorry to ask a question here, but I really don't know what this means or if I need to do the fix with such ludicrous numbers
 (I'm getting 614649.388 per minute).

225 Load_Cycle_Count 0x0032 100 100 000 Old_age Always -
       64424510589

  9 Power_On_Hours 0x0032 099 099 000 Old_age Always -
       665

Revision history for this message
wandlerer (jwandler) wrote :

I just purchased one of the new "Green" WD 500GB drives.

This is a desktop, 3.5" SATA drive.

It is the first desktop drive that I found which monitors 193 Load / Unload cycles.

After less than a week of use, I am already up to over 5500 load cycles. I can hear it clicking as well, once or twice per minute.

I try the hdparm command as root: #hdparm -B 254 /dev/sda

and it comes back with:
/dev/sda:
 setting Advanced Power Management level to 0xfe (254)
 HDIO_DRIVE_CMD failed: Input/output error

I'm thinking the load cycle increasing is similar to the laptop version - since it is based on power savings.

Can anyone else confirm this?

Drive model #: WD5000AACS

Is there a fix for the hdparm error? Am I doing something wrong?

Revision history for this message
_oOMOo_ (hermann-blaxhall) wrote :

Over the last 2 days the updates to Ubuntu Hardy beta have brought back the load_cycle_count increase on my laptop. Have added "hdparm -B 192 /dev/sda" to /etc/rc.local but this is a regression; it has been fine until now.

Revision history for this message
Akshay Srinivasan (akshay.srinivasan) wrote :

I've been using this nifty little script which accesses the hard disk
every 7 secs (like windows :) ) so that the disk head isn't parked,
surprisingly enough , the temperature remians at around 44C ,whereas
with the -B 255 it would easily soar to around 52C.Could anyone here
check if it works on their system ??
(run it with sudo , sudo ck.sh <device path> )

#!/bin/sh
hdparm -B 128 $1
while : ;
do
smartctl -a $1 | grep Load
sleep 7
done

Revision history for this message
desasta (mardox) wrote :

Just installed Hardy Beta with full updates on my Thinkpad R61 (8919-6VG).
This problem is present on this laptop and i fixed it with the solution described on the forums
http://ubuntuforums.org/showpost.php?p=3675960

Attached are some infos about my HD.

Revision history for this message
Frédéric Petit (fraiddo) wrote :

hello,

i have the same problem on a acer 3610 : i have one "click" on the disk by minute, when i'm do nothing on the pc... i can install hdparm? i have only one pc, and i can't do anything for correct this bug, so please fix it :(

thanks,
fred

Revision history for this message
linovski (avelinorego) wrote :

I'm with ubuntu hardy and in few time:
193 Load_Cycle_Count 0x0032 047 047 000 Old_age Always - 106758

I believe that this power save setting , should be enable in some way by the user, with warning advise.

Revision history for this message
Igor Nikolic (i-nikolic) wrote :

As a reply to wandlerer, an attempt to get some more information .

I have the WD GP 500 gb as well. Device Model: WDC WD5000AACS-00ZUB0

Monitoring the HD over 13 minutes recorded a Load_Cycle_Count increase by 28. All
 mount points are mounted with noatime,nodiratime in the fstab.

So, a little over 2 times per minute. Assuming the 600000 cycles mentioned in this thread, this gives it a lifetime of around 193 days of continuous uptime. However, WD advertises the head parking behavior as a feature : http://www.wdc.com/en/products/greenpower/technology.asp?language=en . So I wonder how bad is this really is.
In other words, does the 600,000 cycles figure really hold for these drives ?
Plus, should we expect a (really cheap) low power desktop drive to actually work after almost 200 days of continuous use ? Considering that my machine is only on for a few hours per day max, it will be way past warranty before the thing fails.

So, in order to shed some light on the situation, I figured, I will send WD a email via their "Ask WD a question " page ( http://wdc.custhelp.com/cgi-bin/wdc.cfg/php/enduser/ask.php?p_sid=X-3hQ_*i&p_accessibility=0&p_redirect=&p_lva=1679 )

Here it is :
----
Subject : Rapid increase in Load_Cycle_Count
Dear WD,

This thread on the Ubuntu Launchpad bug tracking system : https://bugs.launchpad.net/ubuntu/+source/acpi-support/+bug/59695/

talks of hard drives getting parked / unparked very often (several times per minute) and suggest that this would damage the drives too early. The idea is that there is a maximum of around 600000 load cycles before the drives fail. This is caused by an aggressive power saving regime of most linux distributions. I can confirm that under normal desktop operations the drive parks up tot 2 times a minute.

Since the GP series is advertised as having the parking feature to save energy, I wonder what is a "normal" frequency of HD head parking under desktop use, and what would be the maximum of load cycles these drives can reasonably expect. Am I going to wreck my HD too early by trying to save power, or did your designers take this into consideration?

Eagerly awaiting your response

Greetings
Igor Nikolic
p.s. The text of this email was posted on the above mentioned forum, in order to help others with similar questions. Your reply will be posted there too.
----

So, lets see what they have to say on this issue. I wont be holding by breath though....

igor

Revision history for this message
Igor Nikolic (i-nikolic) wrote :

Oh, and as a confirmation of the hdparam thing on the WD GP 500 :

~$ sudo hdparm -B 254 /dev/sda

/dev/sda:
 setting Advanced Power Management level to 0xfe (254)
 HDIO_DRIVE_CMD failed: Input/output error

Revision history for this message
Frédéric Petit (fraiddo) wrote :

the bug is corrected?

Revision history for this message
Nizar Kerkeni (nizarus) wrote :

not yet :)

Revision history for this message
Daniel Hahler (blueyed) wrote :

For your information, bug 89269 has just been fixed for Hardy, which did not call hdparm on any of the devices, when (de)activating laptop mode.
This may actually interfere with any workarounds you have put in place, so please report regressions at bug 89269 (for email users: https://launchpad.net/bugs/89269)

Revision history for this message
gunsarebad (rjonesmoo) wrote :

Does that resolve all issues related to this bug too?

Revision history for this message
Matt LaPaglia (mlapaglia) wrote :

Just an observation:

I've run through the diagnostics to see if this bug is affecting me, currently I am at 20.790403139 loads per hour (233102 loads / 11212 hours powered on)

While my hard drive is idling, and the hard drive parks, it spins back up _immediately_ , _every_ time. The estimated load count for my drive (ST9100824AS) is 600,000, so I'm only a little a head of schedule (I have been running Windows XP/Vista before Ubuntu on this drive.)

Wouldn't one presume that a hard drive park = it isn't being used = it would stay parked longer?

Revision history for this message
Igor Nikolic (i-nikolic) wrote :

As a reply to myself at : https://bugs.launchpad.net/ubuntu/+source/acpi-support/+bug/59695/comments/431
WD got back to me with this reply :

---
Dear Igor,

Thank you for contacting Western Digital Customer Service and Support.

The drives have a minimum life of 600K cycles. There is a utility that you can run to alter to a max of 25 seconds, or disable the load/unload cycles the drive performs. It is recommended to alter the load/unload cycles rather than a complete disable.

Please see the attached file.

Sincerely,
Michelle D.
Western Digital Service and Support
http://support.wdc.com
---

On their support site I found a program called wdidle3.exe.
The accompanying wdidle3..txt says :

---
WDIDLE3 Version 1.00 for DOS

DESCRIPTION

- DOS Level utility to setup or report the idle3 value.

FEATURES

- Scan for all drives. Non-WD Drives shall only show the model and serial

  numbers.

- Uses a Vendor Specific Command to set or get the idle3 timer.

- Timer can be set from 100 ms to 25.5 seconds, in 100ms increments.

USAGE

WDIDLE3 [/S[<Timer>]] [/D] [/R] [/?]

where:

/S[<Timer>] Set timer, units in 100 milliseconds (1 to 255). Default=80.

/D Disable timer.

/R Report current timer.

/? This help info.

DOS ERRORLEVEL

0 No error

1 Drive problem

254 Internal program error

255 Invalid command line argument
---

Since I do not have a floppy drive on this machine, and after a few hours of unsuccessful fiddling with FreeDos booting from a USB drive, I still have no idea if this helps.

But there is an interesting stuff in the text file. The default is 80, so 8 seconds. That would mean that the drive is sent to park every 8 seconds? The other weird thing is that the maximum is 25 seconds. That would be worse then the number of parks right now. Or am I reading this wrong ?

Anyway, I hope somebody finds this info useful. If not, sorry for spamming...

Igor

Revision history for this message
Ryan Waldroop (ryan.waldroop) wrote :

Daniel Hahler wrote on 2008-04-14:
>>For your information, bug 89269 has just been fixed for Hardy,
>>which did not call hdparm on any of the devices, when (de)activating laptop mode.
>>
>>This may actually interfere with any workarounds you have put in place, so please
>>report regressions at bug 89269 (for email users: https://launchpad.net/bugs/89269)

This still does not appear to be fixed. Maybe it's gotten a little better, but my laptop
Hard Drive is still parking at least sever times a minute while plugged into AC.

Actually, it's probably more annoying now, because I've been using the posted fixes
for several months and haven't heard that annoying clicking for a while. :)

Changed in laptop-mode-tools:
status: In Progress → Confirmed
Revision history for this message
revelationman (brianwmarto-gmail) wrote :
Download full text (9.9 KiB)

I have to agree with you I have Hardy though I do see many improvements this is a major concern but it appears this is not resolved. I have gone through 3 drives already but sadly Ubuntu cannot get this fix they will loose user's hard drives for laptops are not cheap.

What is sad is that Hardy is very smooth boot times are great my laptop does not get hot like it did and then this nonsense with the hard drive still rears it's ugly head.

So if you do see anything that I missed or did wrong please advise me if I am correct sadly I will go back to Windows XP which I really do not want to.

Maybe I am not doing this right but here is my stats

 Load_Cycle_Count 0x0032 084 084 000 Old_age Always - 32851
 Power_On_Hours 0x0032 100 100 000 Old_age Always - 378

You can get the average per hour by the following division:
Load_Cycle_Count / Power_On_Hours

That works out to 86.907407407 YIKES !!!!

Just in case I did it wrong I will post my entire results

=== START OF INFORMATION SECTION ===
Device Model: ST9120822AS
Serial Number: 5LZ34Z5F
Firmware Version: 3.ALB
User Capacity: 120,034,123,776 bytes
Device is: Not in smartctl database [for details use: -P showall]
ATA Version is: 7
ATA Standard is: Exact ATA specification draft version not indicated
Local Time is: Sat Apr 26 08:46:19 2008 BST
SMART support is: Available - device has SMART capability.
SMART support is: Enabled

=== START OF READ SMART DATA SECTION ===
SMART overall-health self-assessment test result: PASSED

General SMART Values:
Offline data collection status: (0x82) Offline data collection activity
     was completed without error.
     Auto Offline Data Collection: Enabled.
Self-test execution status: ( 25) The self-test routine was aborted by
     the host.
Total time to complete Offline
data collection: ( 426) seconds.
Offline data collection
capabilities: (0x5b) SMART execute Offline immediate.
     Auto Offline data collection on/off support.
     Suspend Offline collection upon new
     command.
     Offline surface scan supported.
     Self-test supported.
     No Conveyance Self-test supported.
     Selective Self-test supported.
SMART capabilities: (0x0003) Saves SMART data before entering
     power-saving mode.
     Supports SMART auto save timer.
Error logging capability: (0x01) Error logging supported.
     No General Purpose Logging support.
Short self-test routine
recommended polling time: ( 1) minutes.
Extended self-test routine
recommended polling time: ( 111) minutes.

SMART Attributes Data Structure revision number: 10
Vendor Specific SMART Attributes with Thresholds:
ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_FAILED RAW_VALUE
  1 Raw_Read_Error_Rate 0x000f 100 253 006 Pre-fail Always - 0
  3 Spin_Up_Time 0x0003 099 099 000 Pre-fail Always - 0
  4 Start_Stop_Count 0x0032 100 100 020 Old_age Always - 242
  5 Reallocated_Sector_Ct 0x0033 100 100 036 Pre-fail Always - 0
  7 Seek_Error_Rat...

Revision history for this message
Ryan Waldroop (ryan.waldroop) wrote :

revelationman: please see the Ubuntu Forums thread that was linked in the first post of this bug: http://ubuntuforums.org/showpost.php?p=3675960&postcount=26

Follow those instructions carefully and it should fix your problem.

Revision history for this message
Brian Ealdwine (eode) wrote : Re: [Bug 59695] Re: High frequency of load/unload cycles on some hard disks may shorten lifetime

As far as disks getting hot, 42 - 57 is pretty normal for most disks.
57-60 is pushing it, and and above 60 is excessive.

The largest threat for disks isn't from heat, it's from the load/unload
cycles (although there should be some kind of shutdown mechanism for hd
temp, if there's not).

Using the /etc/pm/<config.d/power.d>/disk files works fine for me.
System not running hot, and not having problems with the hd cycles.

-Brian

Revision history for this message
Chris Cheney (ccheney) wrote :

I see this problem on the hard drive in my laptop as well.

Hitachi HTS541616J9SA00 (Travelstar 5K160)

Under Ubuntu it increments the load_cycle_count at least every 9s or so.

I booted into Vista to attempt to see if it had the problem under it as well but I couldn't come up with anything conclusive since Vista would NEVER stop reading/writing my drive even though I was doing nothing on the machine. It was still reading/writing at 0.5-1MB/s according to resource monitor an hour after it had booted. I never actually use Vista (other than for firmware updates) so I may try doing a clean install using the information from http://forum.notebookreview.com/showthread.php?t=120228/ , and then see if I can get it to stop constantly writing to my drive with none of the vendor supplied bloatware installed.

Revision history for this message
Magnus S (magnuss) wrote :

This bug also affects my Dell Inspiron 1525n. Not in Gutsy, but in Hardy.

---
Device Model: WDC WD2500BEVS-75UST0
Serial Number: WD-WXC108163731
Firmware Version: 01.01A01
---

The Load_Cycle_Count value climbs by 1 about every 10 seconds or so.

However, this can be fixed with the hdparm -B 255 /dev/sda command.

//magnus

Changed in laptop-mode-tools:
status: Confirmed → Fix Released
Revision history for this message
revelationman (brianwmarto-gmail) wrote :

Well I am surprised this bug was overlooked in Hardy,
It does angers me that is was not corrected, my friends all want Ubuntu on their laptops and I am saying to them not to install it till this issue is corrected..
You must understand as a PC Tech if I recommend Ubuntu to laptop user's and their drives die in 6 months well you can imagine what they will say to me.
I do not want to install scripts and all that bs sorry hopefully they correct it and release a update
So to bug team time to burn the midnight oil and get this fix,

Revision history for this message
Akshay Srinivasan (akshay.srinivasan) wrote : Re: [Bug 59695] Re: High frequency of load/unload cycles on some hard disks may shorten lifetime

Is this really a bug with Ubuntu - Linux in general. As far as I've
observed , this seems to be inherent to the Hard disks. I'm guessing
these parameters were set , keeping Windows in mind.

Revision history for this message
unggnu (unggnu) wrote :

I don't think this is a general Linux problem. I had this under Windows XP too. It has something to do with the Advanced power management which seems to be set to 128 per default from the hard disk producer which lets the hard disk sleep after a short time. At least under Linux it is very easy with one line in /etc/rc.local to set the value to 255.
hdparm -B255 /dev/sda
I don't see the problem and it doesn't seem to kill the hard disk so fast otherwise much more people had huge problems and the producers wouldn't ship them with activated advanced power management.

Revision history for this message
revelationman (brianwmarto-gmail) wrote :

If you are saying they are keeping these parameters for Windows, then if you think of it Linux has to adjust. I was just talking to a Seagate rep and he states there is no reason the drive should fail in Linux . So with that in mind the issue possibly with Linux so as I said this is a bug within Linux .

I just want a fix that is all i do not want some scripts

This is a great system and I know all of us here just want to make it even better

Revision history for this message
thebrotherofasis (libardoab) wrote :
  • unnamed Edit (1.8 KiB, text/html; charset=ISO-8859-1)

Well... I do think that if this issue were given a serious solution, many
laptop users would not hesitate to install ubuntu on their machines. I am an
average user, as most people out there, and many people would get confused
about having to run special commands to fix this issue. Moreover, they would
feel unsecure about it.

I agree with the idea that a serious approach / patch should be found soon,
so that it is definitively corrected, and stops creating concern among
laptop users, as me.

Are there any plans to really solve this soon?

On Tue, Apr 29, 2008 at 1:40 PM, unggnu <email address hidden> wrote:

> I don't think this is a general Linux problem. I had this under Windows XP
> too. It has something to do with the Advanced power management which seems
> to be set to 128 per default from the hard disk producer which lets the hard
> disk sleep after a short time. At least under Linux it is very easy with one
> line in /etc/rc.local to set the value to 255.
> hdparm -B255 /dev/sda
> I don't see the problem and it doesn't seem to kill the hard disk so fast
> otherwise much more people had huge problems and the producers wouldn't ship
> them with activated advanced power management.
>
> --
> High frequency of load/unload cycles on some hard disks may shorten
> lifetime
> https://bugs.launchpad.net/bugs/59695
> You received this bug notification because you are a direct subscriber
> of a duplicate bug.
>

Revision history for this message
revelationman (brianwmarto-gmail) wrote :

Exactly!!!!

We can go back forth and discuss but in the end it is up to Ubuntu team to fix this or find some solution. If Ubuntu is really serious of giving the public a serious alternative to Windows well this would be a good start.
Many people today are going away from the big towers to laptops and portables so fixing this issue could bring more user's over to Linux and Ubuntu in general.
I do feel Ubuntu Hardy is a better system then Vista but this issue has to be fixed.
When this is fixed I will recommend Ubuntu to laptop user's right away but as I stated earlier I cannot do that with this bug present.

Revision history for this message
Penguinnerd (ab-beadle) wrote :

^ I agree, it is a problem that can/should be solved by the Ubuntu team, whether they caused it or not.

Even if it wasn't their fault, they should still fix it because it would make Ubuntu much more credible. (But I very much suspect that it is their fault)

As much as I appreciate Ubuntu for introducing me to Linux, I must say that I am losing faith in the developers. They make great software, but they overlooked this one serious problem.

Revision history for this message
CTenorman (ctenorman) wrote :

I likewise must concur. I strongly support the open source movement, and like to help people switch to open source solutions on their computer. As other distributions continue to fix this problem, and Ubuntu doesn't, I'll have to tell them to avoid Ubuntu like the plague and install the distributions with the fixes pre-installed.

I really don't want to have to do this. However, I'm simply going to have to do so because if there's one distribution that won't destroy someone's hard drive, and another that will, it would be irresponsible of me to give them something that would trash their computer and data.

This is quite possibly the most important bug in Ubuntu right now. If a fix is not forthcoming quickly, I'll simply have to stop installing Ubuntu on other computers, and cease using it myself so that I can be familiar with the distribution that I help others install.

Please fix this bug before I'm forced to leave this otherwise excellent community.

Thank you.

Revision history for this message
Brian Ealdwine (eode) wrote : Re: [Bug 59695] Re: High frequency of load/unload cycles on some hard disks may shorten lifetime

On Tue, 2008-04-29 at 18:40 +0000, unggnu wrote:
> I don't think this is a general Linux problem. I had this under Windows XP too.

I don't care whose problem it is -- if we can do something about it, we
should. ..at the very least we should expose users to it and allow them
to choose, in a simple fashion, which they want. It could even be
something that's monitored, and checked against a hw db, or just checked
once every hour / every two hours, and notifies the user if there's
significant load cycle increase. In hardy, (not for all cases, but for
many, and probably most) it's as simple as installing two small files
in /etc/pm.

> I don't see the problem and it doesn't seem to kill the hard disk so fast otherwise
[snip!]

I lost two disks to this early on.

-Brian

Revision history for this message
Brian Ealdwine (eode) wrote :

Vast parts of the system's structure are 'just scripts'.

> I just want a fix that is all i do not want some scripts

..there are properly-created scripts available for hardy. I can post
them here, if it's of use (and likely to be used by the bug fixers). I
can send them to you personally if you like. However, these scripts
should be a part of the base install!

> This is a great system and I know all of us here just want to make it
> even better

*nod*

Revision history for this message
Ryan Waldroop (ryan.waldroop) wrote : Re: [Bug 59695] Re: High frequency of load/unload cycles on some hard disks may shorten lifetime
Download full text (3.8 KiB)

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I've been trying to keep my personal opinions in this matter to
myself, as this is not a forum for discussion but rather a place for
work. Instead of work being done to actually *fix* the problem, all
I've been reading are thinly veiled "threats" against Ubuntu...people
wanting to leave because of this.

This is outrageous! This bug affects me, yes, but it does *NOT*
affect all users. How would each of you propose that Ubuntu "fix"
this problem? There's been multiple solutions provided in this
thread...Do they throw a dart at them while they hang on the wall?
Some people here have reported that certain "fixes" dramatically
increase temperature. This causes problems not only for the HDD but
also for other components that could succumb to the added heat. Some
people require an hdparm 254, others a 255. Some need 192, others
128, others somewhere in between. What would you propose as the
default? You can't *possibly* pick just one, because you could
destroy someone's computer that way.

No, instead, the Ubuntu developers are trying their hardest (I'm sure)
to find and write a fix that is a safe and viable solution for
/everyone/. As of now, it's a simple matter to fix for the users that
it most directly impacts...It's much easier for 1 person to see which
of 3 or 4 fixes works on 1 machine than for many devs to see what
works across the board on thousands of machines.

Now for my pet peeve: several people have posted that they "work" in
IT or Tech Support, and they seem to imply that they are constantly
helping non-linux-literate people switch to Ubuntu and other OSS, and
this one bug is keeping them from doing that. This is a MAJOR red
flag to me. Tech Support is all about a *personal* touch. You are a
branch, a lifeline, between the user and the rushing river of
technology. You have to be able to sit down and spend time with each
person. Sure, some people are like you and I...able to sit down and a
computer and click at things until we figure it out. Others NEED
HELP. That's why we get paid what we do to *help* them. I have
successfully switched many people to Ubuntu, but ONLY because I took
the time to install it and configure it to their needs first. Could
you imagine a brand new, scared to click and look around, user trying
to install flash from the Adobe website? Or attempting to download
MSN or AIM because they didn't know what Pidgin was? No, when someone
first switches it's necessary to show them the basics and make sure
everything works. The last user I switched was a French girl studying
in America. When I installed Ubuntu, she had a DPI problem that
involved editing in a terminal to fix. Once that was done, I checked
this bug (which didn't affect her), and took the time to show her the
ropes--installing programs, switching from english to french, using
firefox, pidgin, and an "MS Office" (compatible) suite.

In closing, if you are going to switch, fine. If you are going to use
Ubuntu, great! If you want to help, then please fix bugs or spread
the word or make artwork...THANKS! If you have a problem, then just
remember that this is OPEN SOURCE SOFTWARE. That me...

Read more...

Revision history for this message
Brian Rogers (brian-rogers) wrote :

If Ubuntu can do something, Ubuntu should do something. I agree with that. However, just because a company puts out some buggy hardware, that shouldn't force people with well-behaved hardware to lose power management. And we certainly shouldn't harm the longevity of the drives that were actually built right in order to patch up the drives that weren't. Doing so, and protecting the manufacturers from their own stupidity, would just be begging for more of the same.

Also, if it became a standard behavior for operating systems to disable power management on drives, the manufacturers would just program their new drives to ignore that command. That would be bad for a variety of reasons, including the possibility that this problem still exists, but now there's no workaround.

Remember, this affects ALL operating systems, Windows included. Only Linux distributions have actually done something about it. But even those Linuxes don't fix the problem for everyone and those people that don't need the fix are worse off with it enabled.

Monitoring the load cycles and activating a workaround if they're increasing too fast is a good idea. In fact, it's the first general, workable solution I've seen anyone propose.

Revision history for this message
ethanay (ethan-y-us) wrote :

Dell XPS m1330 laptop running hardy 8.04 with latest

none of the ugly fixes above or others that I have encountered elsewhere have worked; HDD apm value (hdparm -I /dev/sda) after resume from suspend or hibernate persistently resets to 128. I get about 5-8 load/unloads per minute. I have tried adding scripts to /etc/acpi/*.d/, tried the etc/pm/disk fixes, and tried the hacks which sync hdparm values with ac/battery modes while enabling laptop-mode via acpi-support. Nothing seems to be working in hardy where it worked in gutsy. so i am still entering hdparm -B 254 /dev/sda manually after each resume from suspend or hibernate.

Is this a separate bug or part of the same bug and bug fix? Would any more information be helpful?

thanks,
ethan

PS seems to me a lot of people have been blaming each-other. This isn't *just* a hardware issue, and it's not *just* a software issue. For my drive, a default APM value of 128 would be sane IF the software operating on it was written with that value in mind. But it wasn't. Likewise, Ubuntu's frequent disk access would be sane IF the hardware it's operating on was programmed with that in mind. But it wasn't. The incompatibility isn't really anyone's fault unless we can somehow get hardware manufacturers and Linux software developers to agree on shared specs. It would be wonderful if something like this was in the works.

But in the mean time, the hardware defaults can be changed via software, which leaves the burden of closing the "insanity gap" solely on Linux software developers by a) changing the hardware defaults and b) finding ways to sync hdd i/o requests from the OS and other software if/whenever the APM is set aggressively. Without that, we'd just be killing our hard drives and reducing performance without any added power saving or bump protection.

Revision history for this message
revelationman (brianwmarto-gmail) wrote :

It would be nice if we get an official response from Ubuntu on this and what are their plans on correcting the issue.
"Ubuntu is a community developed, Linux-based operating system that is perfect for laptops, desktops and servers."
I can agree but not on laptops sure the software that comes with it is great but this issue does not make it good for laptops.
This issue has been around for a few years it could be one this issue 's that will not have a proper resolution.
Well we can write back and forth on this all day folks but is it doing any good we placing and modifying things that we should not, in the end it is up to the Ubuntu Team to correct this not us.
If the people want this is Linux Distro to be widely accepted then they must find a solution or gives us a official response on their plans.
I have just read that many people are calling Windows Vista the next Windows ME so this is a great time for linux and ubuntu to start converting new user's but again correcting this problem would be a great first step.

Changed in laptop-mode-tools:
status: Fix Released → Confirmed
Revision history for this message
der74hva3 (der74hva3) wrote :

real

Revision history for this message
Chris Cheney (ccheney) wrote :

This is most definitely a "bug" in the hard drive firmware settings in how quickly it parks the head after being idle. It affects MacOS X and Windows users along with Linux users in general not just Ubuntu. I have found posts on other sites referencing the problems for their users as well. The only thing those users were able to do about fixing the problem was to turn off the power management completely by doing the equivalent of hdparm -B 254 (setting the register to 0xFE). I have included links below referencing the problem showing up on the other OSes.

Completely disabling power management however will cause the head never to park and if the system is jolted could potentially cause the hard drive heads to crash into the platter. So 'fixing' this across the board by disabling head parking altogether is not really a good solution either.

Probably the only reason some users don't see this behavior under Windows but do under Linux is that their Windows install probably never allows the drive to be idle enough to park the head. This was the case on my machine before I cleaned off the OEM install which had lots of bloatware on it and reinstalled Vista from scratch, it would never stop writing to the disk. Which would also mean if the drive is jolted too hard it would crash as well. So no Windows doesn't have this problem 'fixed'.

My post on ubuntuforums.org about it:
http://ubuntuforums.org/showthread.php?p=4830919

MacOS X:
http://discussions.apple.com/thread.jspa?messageID=7055342

Windows:
http://forum.notebookreview.com/showthread.php?t=191167

So the ball is in the manufacturer's court in that they need to adjust the head parking idle time to something more sensible, or at least provide utilities that can allow the user to tweak the setting. Hitachi for one does not provide this ability.

Revision history for this message
revelationman (brianwmarto-gmail) wrote :

I went back to Ubuntu after speaking to the Seagate Tech I have a 5 year warranty and I have another drive (Seagate) with a 5 year warranty.
I personally cannot stand Vista to me it is Windows ME all over again it is bloated and with over 50 million lines of code ( so that say) it does not make sense.
Hopefully the Ubuntu team can figure this out, the word from Seagate is their drives can run Linux.
So I will wait for a patch if drive dies so what I will send it back for warranty and then place the other drive in and let that die just one big cycle
I feel the issue is within Linux that is my feeling it could be something very silly maybe a power management setting just for laptops who knows.
But I am keeping the faith .

Chris Cheney (ccheney)
description: updated
description: updated
Chris Cheney (ccheney)
description: updated
Revision history for this message
Brian Ealdwine (eode) wrote : Re: [Bug 59695] Re: High frequency of load/unload cycles on some hard disks may shorten lifetime

> Nothing seems to be working in hardy where it worked in gutsy.
> so i am still entering hdparm -B 254 /dev/sda manually after each resume
> from suspend or hibernate.

There are limitations to the /etc/pm/xx/disk solution. If I have time,
I'll spend some of it to improve it.

..erh, that is, since it's trivial to improve it, I just improved it.

Previously, the 'disk' files only applied to one disk (because only one
disk is listed in one 'disk' file, *and* because there is a quoting
error in the other 'disk' file. I've edited them, and they now include
disks /dev/sd[a-z], and all disks /dev/hd[a-z]. (originally they only
included /dev/sda).

Either way, you should check that your root disk is in the list. option
is that you can look and find out what disk it is that your system root
is, and make sure that's the disk in the config.d 'disk' file.

> Is this a separate bug or part of the same bug and bug fix? Would any
> more information be helpful?

If you are having the problem, and you are able to disable your disk's
pm with the hdparm command, than it is *not* a separate bug.

If you are having the problem, and you are *unable* to change your
disk's pm with the hdparm command, then that *is* a separate bug --
namely, a bug to be filed with hdparm.

Also, make sure that the resulting 'disk' files in the /etc/pm/config.d
and /etc/pm/power.d are executable.
[CODE]
chmod a+x /etc/pm/config.d/disk /etc/pm/power.d/disk
[/CODE]

> But in the mean time, the hardware defaults can be changed via software,
> which leaves the burden of closing the "insanity gap" solely on Linux
> software developers [snip]

*nod* it's not an issue of fault, it's an issue of who can do something
about it. :-)

Revision history for this message
Brian Ealdwine (eode) wrote :

Good info!

It shouldn't be too difficult to include a script that monitors the
system for the bug, to be run by cron, then notifies the user, providing
an option to automatically disable power management on the disk if so.
I could do that. Is there a way I could get it published, if I did make
such a script?

On Thu, 2008-05-01 at 06:58 +0000, Chris Cheney wrote:
> This is most definitely a "bug" in the hard drive firmware settings in
> how quickly it parks the head after being idle. It affects MacOS X and
> Windows users along with Linux users in general not just Ubuntu. I have
> found posts on other sites referencing the problems for their users as
> well. The only thing those users were able to do about fixing the
> problem was to turn off the power management completely by doing the
> equivalent of hdparm -B 254 (setting the register to 0xFE). I have
> included links below referencing the problem showing up on the other
> OSes.
>
> Completely disabling power management however will cause the head never
> to park and if the system is jolted could potentially cause the hard
> drive heads to crash into the platter. So 'fixing' this across the board
> by disabling head parking altogether is not really a good solution
> either.
>
> Probably the only reason some users don't see this behavior under
> Windows but do under Linux is that their Windows install probably never
> allows the drive to be idle enough to park the head. This was the case
> on my machine before I cleaned off the OEM install which had lots of
> bloatware on it and reinstalled Vista from scratch, it would never stop
> writing to the disk. Which would also mean if the drive is jolted too
> hard it would crash as well. So no Windows doesn't have this problem
> 'fixed'.
>
> My post on ubuntuforums.org about it:
> http://ubuntuforums.org/showthread.php?p=4830919
>
> MacOS X:
> http://discussions.apple.com/thread.jspa?messageID=7055342
>
> Windows:
> http://forum.notebookreview.com/showthread.php?t=191167
>
> So the ball is in the manufacturer's court in that they need to adjust
> the head parking idle time to something more sensible, or at least
> provide utilities that can allow the user to tweak the setting. Hitachi
> for one does not provide this ability.
>

Revision history for this message
Wiktor Wandachowicz (siryes) wrote :

Brian Visel:
> Is there a way I could get it published, if I did make such a script?

Add an attachment to this bug report so the devs could decide?

Revision history for this message
houstonbofh (leesharp) wrote : Re: [Bug 59695] Re: High frequency of load/unload cycles on some hard disks may shorten lifetime

Brian Visel wrote:
> Good info!
>
> It shouldn't be too difficult to include a script that monitors the
> system for the bug, to be run by cron, then notifies the user, providing
> an option to automatically disable power management on the disk if so.
> I could do that. Is there a way I could get it published, if I did make
> such a script?

If you can put your fix in a deb, you can host it in a personal package
archive on an ubuntu site. https://help.launchpad.net/PPAQuickStart
After some peer review, it could be picked up by the main distribution,
or at least used by many people. It could also be contributed to by
others. It would be a small project, but a popular one. The ntfs r/w
automount and autofsck started out in ways similar to this.

Revision history for this message
ethanay (ethan-y-us) wrote :

Brian: I've replaced the old config.d/disk and power.d/disk files with the updated ones and made them executable as you've directed, and the APM level is still reset back to 128 after resume from suspend/hibernate.

Since I can manually enter
sudo hdparm -B 254 /dev/sda
in a terminal and change the APM value in order to stop the excessive load/unload cycling, I guess I am experiencing the same bug.

But either the scripts aren't working at all, or something else is overriding them. I don't know what this could be, or what additional information to provide. Is it possible that it's just a setting somewhere that I have to change, or that I am experiencing another bug on top of all this?

Revision history for this message
Ryan Waldroop (ryan.waldroop) wrote :

ethanay: have you tried adding your script to /etc/acpi directories per the ubuntuforums post?
http://ubuntuforums.org/showpost.php?p=3675960&postcount=26

Also, you should be able to run "sudo hdparm -B 254 /dev/sda" on startup by adding it to System > Preferences > Sessions.

Revision history for this message
ethanay (ethan-y-us) wrote :

Ryan: Thanks for the suggestions. That brings up an important distinction: startup settings are fine (APM 254). The problem is specifically with resume from suspend or hibernate.

The link you provided was the first solution that I tried, with no success.

Revision history for this message
unggnu (unggnu) wrote :

Why not using the laptop-mode which is installed per default but only has to be enabled? It has an option for setting advanced power management and if it is added to STOP_SERVICES in /etc/default/acpi-support it sets APM even after suspend resume.

Revision history for this message
Akshay Srinivasan (akshay.srinivasan) wrote : Re: [Bug 59695] Re: High frequency of load/unload cycles on some hard disks may shorten lifetime
  • i.sh Edit (314 bytes, application/x-shellscript; name="i.sh")

I finished writing a simple Shell script for monitoring the disk-head
activity.Once started , it beeps if the number of parks exceed a preset
limit , within the given interval of time.You need to have beep
installed for it to work.

P.S : - Running smartctl usually brings the disk out of idle , so don't
set the interval to a very small value.Also , the script needs to be run
with sudo.

Revision history for this message
ethanay (ethan-y-us) wrote :

I've tried all the above, to no avail. Even with laptop mode enabled, and set to execute on resume (laptop_mode is enabled after resume), apm = 128 and I have to change the setting manually. I'm beginning to think this might actually be another bug, unless someone has some suggestions about where to look for something that is over-riding anything and everything that I do to maintain hdd apm settings after resume. It is also extremely confusing to have apm, acpi, hdparm, laptop-mod, and pm-utils (and any others?) potentially controlling the same settings. Thoughts?

Revision history for this message
Dan McGuirk (incandenza) wrote :

I would recommend taking a look at bug 89269. The real problem, at least for me, is that the hdparm settings that are supposed to take place in power.sh when you have LAPTOP_MODE_ENABLED actually only take place when you change power sources, not when you resume from a suspend. See Valentin Neacsu's most recent comment in bug 89269 for a workaround that fixes the problem for me.

Revision history for this message
xzirrow (xzirrow) wrote :

Hi, all.

As I wrote here before (look above), i've tried many things and solutions. Now my HDD working fine, no Load_Cycle clicking, no hdd overheat.
It works normal for 5 months already.

Look what I've done

sudo aptitude purge acpid
sudo aptitude purge acpi-suport

I thought if this acpi scripts done so, than it will be better to turn them off, and use default settings of firmware But afterwhat it still was Load_Cycle increase,
and in a short time i've decided to turn it back.

sudo aptitude install acpid
sudo aptitude install acpi-support

but system said after downloading - it can't configure packages . I've killed all acpid processes

kill ACPID_PID (get it from ps)
and use dpkg --reconfigure acpi-support .

And now it work's, completly fine and even after suspend (I'm not on laptop-mode)
And try it for YOUR OWN RISK

Revision history for this message
ethanay (ethan-y-us) wrote :

Confirming (finally!) that my inability to apply any of the various ugly fixes was due to a second bug #89269. Valentin Neacsu's posted workaround has enabled persistent safe hdparm rules for me in Hardy.

Revision history for this message
Alexey Borzenkov (snaury) wrote :

Some more info on the issue. I recently bought a new Samsung HM160HI and started having the issue with Load_Cycle_Count. I tried the solution with setting hdparm -B 255, but what I found is that my drive is already in that mode after reboot. So after hdparm -B 254 Load_Cycle_Count stopped increasing. But what I've found is that after this Load_Retry_Count starts increasing, with an extremely loud click once per several minues, which I found much worse than increasing Load_Cycle_Count.

The real issue, it seems, is that something is constantly waking the disk up, even when disk shouldn't be touched. I've been playing with laptop-mode and a modified iotop.py (which shows actual bytes for each process in batch mode, skipping the ones that don't do any actual io), and found the following. When I set hdparm -B 255, and hdparm -S 4, the disk spins down after 20 seconds, however after a very short time (less than a minute) firefox writes something to disk and pdflush kicks in dropping in, even though /proc/meminfo shows only several kilobytes under "Dirty", while my dirty ratio is 60 percent. Very strange.

Now I suspected that there might be something going on with pagefile, so I swapoff my swap partition and try all this again. Now pdflush no longer kicks in immediately after firefox or other programs. But things get even more fishy. Even without any I/O activity (both my modified iotop.py and gkrellm show absolutely nothing) disk spins down, but shortly after that spins up again.

Why would my disk spin up again without any I/O?

Judging from increasing Load_Retry_Count, it seems to me that my drive parks heads with a purpose (and when you don't let it, something bad happens, i.e. that horrible click as if heads drop from somewhere). But what's wrong here is that something pulls them back. Something is constantly touching the drive when it shouldn't.

p.s. I don't have trackerd installed, and during my tests the only processes that showed up were either none, or firefox and [pdflush].

Revision history for this message
Alexey Borzenkov (snaury) wrote :

Oh my god, it's so stupid. It turned out that my issue was hddtemp running in daemon mode. Because it uses smart (sic!) to query drive temperature, and update interval is hard-coded to 60 seconds, it was waking my drive every 60 seconds! As soon as I disabled it, my problems seem to go away. The drive spinned down and doesn't wake up for several minutes already, just like it should. =^_^=

So for the rest of you, check that you don't have anything checking smart in the background, hddtemp in particular...

P.S. On the side note I find it crazy that to check drive temperature you need to spinup... x_x ...I couldn't even suspect that!

Revision history for this message
Julien Dubois (julien-dubois-deactivatedaccount) wrote :

Thanks ethanay, I had exactly the same two problems as you!
Personnally I've put "hdparm -B 254 /dev/sda" even in battery mode because this "click" sound is driving me crazy. My HD temperature looks OK (42°C).

I'm not sure the problem is 100% solved thus, because I still hear a much fainter "click" sound, which is happening every 1 second approximately, and I also hear my disk spinning quite often without any reason...

Revision history for this message
Åskar (olskar) wrote :

No fix mentioned here works for me..my harddrive is still slowly dying with about 5 loadcycle increased every 10 seconds!

Revision history for this message
Zaar Hai (haizaar) wrote :

Here is the solution for Hardy: http://ubuntuforums.org/showthread.php?p=4886869&posted=1#post4886869
(also read my comment there in the end)

Changed in dell:
status: New → Confirmed
Revision history for this message
Akshay Srinivasan (akshay.srinivasan) wrote :

Did anyone bother trying my script?

Revision history for this message
Brian Ealdwine (eode) wrote : Re: [Bug 59695] Re: High frequency of load/unload cycles on some hard disks may shorten lifetime

On Sun, 2008-05-04 at 11:33 +0000, Åskar wrote:
> No fix mentioned here works for me..my harddrive is still slowly dying
> with about 5 loadcycle increased every 10 seconds!

If *no* fix works for you, and your count is increasing that quickly,
use this script (this really *is* a dirty fix).

[code]
#! /bin/sh
while [ 1 ]; do
    touch /tmp/foobar.tmp
    sleep 3
done
[/code]

(skip the code and /code tags if they aren't interpreted by the
bugtracker -- that was just to put the script in a block by itself. If
it *is* in a block by itself, nevermind.)

That will keep your disk busy enough that it doesn't sleep. If you
need to, decrease sleep 3 to sleep 2.

It would be a lot better if you asked the manufacturers of your disk for
a utility which changes this behaviour, if it's available.

Revision history for this message
Akshay Srinivasan (akshay.srinivasan) wrote : Re: [Bug 59695] Re: High frequency of load/unload cycles on some hard disks may shorten lifetime

Brian :-
    About your fix :- Creating a new file , didn't really do any disk
operation - atleast not immediately - so this means laptop-mode is
actually working.
   Paradoxically , firefox some how does instantaneous write operations-
laptop-mode fails to work here. Is there anyway one can bypass laptop-mode ?

Revision history for this message
Bart Samwel (bart-samwel) wrote : Re: [Bug 59695] Re: High frequency of load/unload cycles on some hard disks may shorten lifetime

Akshay Srinivasan wrote:
> Brian :-
> About your fix :- Creating a new file , didn't really do any disk
> operation - atleast not immediately - so this means laptop-mode is
> actually working.
> Paradoxically , firefox some how does instantaneous write operations-
> laptop-mode fails to work here. Is there anyway one can bypass laptop-mode ?

Laptop mode doesn't disable synchronous operations, so you can add a
"sync" in the loop to flush the change to disk.

Cheers,
Bart

Revision history for this message
Jakob Unterwurzacher (jakobunt) wrote :

This is *really* an ugly fix.
Åskar, have you tried this?
http://ubuntuforums.org/showpost.php?p=4897802&postcount=842

Revision history for this message
revelationman (brianwmarto-gmail) wrote :

Sad reality is that Laptops and Ubuntu do not mix at this moment I have since switch back to Windows XP and the clicking noises are gone, I still run Ubuntu on my desktop that is fine no issue's . All laptops must have power management that is the issue here with Ubuntu .

I am sorry but I do not agree with these temp fixes laptops are not cheap also hard drives, I am confident that update will come but sadly I do not think it will be soon.

Right now I find Windows XP is still the best for running laptops, funny it took Microsoft 6 years to make a stable system.

Revision history for this message
Alexey Borzenkov (snaury) wrote :
Download full text (3.2 KiB)

A note of observation. After I switched back to Windows XP I found that Windows indeed didn't let my drive to spin down or park heads, however all this came at the same price I had in Linux, i.e. frequent superclicks and Load_Retry_Count increasing. So the problem is not with Linux or Ubuntu at all, the problem is solely with the hard drive.

It is also worth noting that with Ubuntu I was able to reach any comfortable increase rates by carefully tweaking /etc/laptop-mode/laptop-mode.conf. The most important are ENABLE_LAPTOP_MODE_ON_AC=1, LOST_WORK_SECONDS (the default value of 360 ensures only 10 Load_Cycle_Count per hour), READAHEAD (which in my opinion shouldn't default to 3072, since huge delays every half or one minute between reads effectively prevent playing videos, setting it to LM_READAHEAD=128 was the best in my case), IDLE_TIMEOUT (if you want your drive to really cool down when idle, in my observation 60 seconds on AC was the best), and WRITECACHE set to one (this adds another good layer of caching by the hard drive).

Now don't forget to set ENABLE_LAPTOP_MODE=true in your /etc/default/acpi-support.

BUT ALL THIS WON'T WORK unless you edit your /etc/acpi/power.sh and do the following modifications:

Comment out all $HDPARM nonsense, since laptop-mode controls this for you (provided you set your settings in laptop-mode.conf, of course). Next, where you see "$LAPTOP_MODE stop" it should be "$LAPTOP_MODE", WITHOUT STOP. The latter is very important, because when "/usr/sbin/laptop_mode stop" is called it effectively TURNS OFF LAPTOP MODE, even if you have ENABLE_LAPTOP_MODE=true in your /etc/default/acpi-support. While calling "/usr/sbin/laptop_mode" without arguments does autodetection, and depending on your settings will either Without laptop mode "lost work seconds" do not work and this means that mount option is not applied and pdflush will drop caches half a second after some program (i.e. firefox) writes something to disk. The constant writing to disk by many applications is what actually causes heads to unpark, and when manufacturer sets some very ridiculous timeout for head parking (i.e. 3 seconds in my case) heads keep unparking all the time.

I'm not sure if acpid is at fault here for calling laptop_mode with stop argument, or laptop_mode not honoring your settings when stop is passed, but current settings make laptop mode effectively useless. When I did the above modifications and tweaked config files for my tastes I was able to get rid of all problems. When my computer is idle heads park and disk spins down, staying untouched for 6 minutes. When I'm doing something active, like watching a movie, my drive is constantly accessed and heads don't park needlessly. When I'm having a mix of the two (like active browsing, or doing something else) my heads unpark only 20-30 times per hour, which I consider very good. And best of all, my drive was not thermally abused and super clicks didn't happen.

As a comparison, average temperature of my drive under Windows was 41 degrees Celsius (and never below), under Linux it was 34-36 degrees Celsius.

I consider that the main issue with this bug is that laptop mode (as it is) DOES NOT W...

Read more...

Revision history for this message
Milan Bouchet-Valat (nalimilan) wrote :

revelationman: did you try the "ugly fix" proposed above? It should be doing exactly what Windows currently does. ;-)
[code]
#! /bin/sh
while [ 1 ]; do
    touch /tmp/foobar.tmp
    sync
    sleep 3
done
[/code]

Ubuntu is not at fault here and I've been using it on many laptops without trouble. The fact is Windows seems to have no power management at all, and is constantly using the hard disk, preventing it from parking. Your hard disk is broken, and sure it would be nicer if Ubuntu could save it, but understand that it's not easy: we can't break all ACPI support because if some lame ducks.

Revision history for this message
okparanoid (okparanoid) wrote :

hi !

That i don't not understand it's why you don't try to detect this problem automatically and let inform the user via notification that the firmware of the disk is defect and propose him to make a "dirty" workaround.

it is just few lines of code to add to the notification system (checking that the number of cycles does not increase too high).

It is a major issue and even it is not directly a linux kernel or ubuntu due i think that it is to the responsability of the distrib to take care of such things when a large amount of users are touched with this.

Cheers !

Revision history for this message
okparanoid (okparanoid) wrote :

Novell/SUSE Bugzilla #338230 is marked as a duplicate of this new one.
See comments for look at the workaround they are working on.

Revision history for this message
Yann (lostec) wrote :

This problem is still there under ubuntu Hardy 8.04 (LTS... but with present settings, my HD will not last 3 years!).
I've a brand new HDD, a WD scorpio 320Gb. Hardy hdparm -B defaults to 128 even on AC power, leading this drive to have heads parked/unparked every minutes. 600000 minutes average lifetime is about 1 year.

Please fix this. Note that I reinstalled from live-CD. previously I was running Dapper (6.06) and never experimented such behaviour.

There is a lot of duplicates of this bug since more than one year now, which is currently read by in charge teams?

The result is we can expect a lot of HDD starting to dead now and furious users that will never run ubuntu or even Linux anymore. So why such a poor reactivity for this critical problem? Having them coming back in mass to Redmond? Shit...

Please also note that common fixes (99* shell scripts in various /etc/acpi/*.d) does not survive restoring from a suspend to ram: acpid seems to override scripts settings after script execution (or do not execute them at all?). This is the behaviour of current 2.6.24 hardy kernel.

A small Heron being "hardy"... I should have been careful. Next is "intrepid" ibex? Holly shit, what must be expected from this "intrepid" one? Machine burning after install?

Regards

Revision history for this message
Dennis Noordsij (dennis-noordsij) wrote :

Just to (re?)state the obvious:

A standard Linux kernel flushes to disk every 5 seconds. I don't know what anyone expects their disk to do to "save power" between those flushes, but it doesn't. When the drive manufacturer sets default settings it is under the assumption the OS is not going to force the disk up every 5 seconds, but rather is going to make an effort to minimize disk access. If the OS knows it needs the disk every 5 seconds, it should explicitly disable APM.

Ubuntu is "at fault" (and I don't mean this offensively!) in that it allows APM to be enabled but does not enable the laptop_mode of the kernel to minimize disk access.

Sure the drive/BIOS default settings are aggressive, sure the disk wants to park after 1 second and spin down after 2 - this would be fine if Ubuntu would minimize disk access, but ANY power saving settings is unacceptable with a standard install which kicks the disk every 5 seconds. Exactly how should it save power that way ?

Without laptop-mode enabled and active there should be no APM enabled at all.

Similarly, for the following and similar quotes:

"So the ball is in the manufacturer's court in that they need to adjust the head parking idle time to something more sensible, or at least provide utilities that can allow the user to tweak the setting. Hitachi for one does not provide this ability."

Linux is forcing the disk up unconditionally every 5 seconds - there is no "sensible setting" for head parking idle time except "off"!

What am I missing that seems to make this such a complicated issue ? When not in laptop_mode, APM must be off. Period. Nothing to do with firmare or BIOS. Nothing to do with settings. Just common sense. If you kick the disk every 5 seconds, APM makes no sense. What is the disk going to do to save power?

Revision history for this message
Milan Bouchet-Valat (nalimilan) wrote :

For me, using a non-broken disk, the heads never park - I'm not using laptop-mode. So there seems to be a problem with the broken disks that makes them park without Linux telling them to do so, and even prevents Linux from avoiding spinning down. Maybe Ubuntu should be able to let the HD sleep for more than 5 sec, but this is another problem.

Revision history for this message
Dan McGuirk (incandenza) wrote :

I find it strange that so many people say there is no possible workaround for their system. If you can stop the problem by applying hdparm -B 255 (or 254) yourself, then the only remaining problem is to make sure that is always applied (particularly after a suspend). If that is the problem, then see the tail comments of bug 89269.

Or are there some drives where even hdparm -B 255/254 does not prevent the parking?

Seems to me the only difference between a "broken" and "non-broken" drive is the default value of this setting, and whether or not it goes back to the default (and hence needs to be changed again by Ubuntu) after a suspend (or reboot).

Revision history for this message
Dennis Noordsij (dennis-noordsij) wrote :

Milo: it just means your disks default settings do not trigger within the 5 seconds of the forced flush. This is purely coincidental and nothing to do with "broken" disks.

It is also the reason so many people see so many different results, depending on your drive's settings you may never see it, or you may see 12 parks per minute.

BUT, this in no way invalidates that it does not make any sense to have any APM when not using laptop_mode, and that it is the cause for the load cycle count increases.

Dan: if APM is 255/254 it should be fixed, but for example on my standard Hardy (with backports) it is re-set to 128 on resume-from-suspend, and goes clickity-click.

If a drive "wakes up" with a different setting than it went to sleep with, fair enough that is stupid on the drives part, but, like many other devices which get reinitialized, the OS should make sure the driver is in the correct state (no APM if it wasn't set before), and that just brings us back to the main issue: no APM when not in laptop_mode

Revision history for this message
Dan McGuirk (incandenza) wrote :

Dennis, I agree with what you're saying; I'm just trying to make sure everyone knows that the problem with not restoring the setting after suspend is described in bug 89269, which also includes a workaround. That bug needs to be reopened or a new bug opened to provide an official fix.

Revision history for this message
Dan McGuirk (incandenza) wrote :

I opened bug 229693 to describe the remaining unsolved problem in bug 89269. I believe a proper fix here would solve this problem for most users (as long as they set the ENABLE_LAPTOP_MODE flag in /etc/default/acpi-support).

Revision history for this message
revelationman (brianwmarto-gmail) wrote :

What I have been saying all along Ubuntu does not work for laptops sorry to say Microsoft is better for laptops, on my laptop now using Windows XP the drive is fine ,

Power management is sticky and sore issue with Ubuntu and if they want to take a bigger bite out of Microsoft this issue has to be resolved.

I still run Ubuntu on a old desktop that is fine but I will not install it on this laptop I have gone through more then 3 drives in less then a year . It just gets to costly and it seems that Ubuntu team is not really doing nothing about it .

FIx it that is all I want and everyone wants is that to hard to ask .

Revision history for this message
ethanay (ethan-y-us) wrote :

my laptop is running extremely well with Ubuntu after some configuration (and a lot of learning on my part). but this isn't a "windows vs linux" thread.

for people without heat problems, the ugly fixes for /etc/pm/*.d/ or /etc/acpi/*.d/ will work just fine. However, for people who have heat problems or require shock protection, the solution is much more complicated. furthermore, a solution for everyone is the most complicated, because it has to take into account both of the previous.

like someone else has pointed out, an ugly fix such as hdparm -B 254 is NOT a viable fix for Canonical to release for everyone because some people are dealing with excessive heat problems. This means that they have to work much harder to develop a more sophisticated solution to the problem that will be OK for everyone: appropriate apm settings for both unoptimized hdd i/o and also settings to optimize hdd i/o to allow for aggressive apm. given the complex software environment that this situation exists in, that takes time to develop and test.

however, i agree with others pointing out that it seems communication from Canonical to the general user population on this issue has been extremely lacking. that seems to me to be the bigger issue that this bug has exposed. either this is a fluke, or Canonical needs to use a more effective communications model in order to get messages out to the general user base.

Revision history for this message
Alexey Borzenkov (snaury) wrote :

I personally think the solution should be simple. First some parameters in laptop-mode need splitting into LM_AC_ and LM_BAT_ (like LM_READAHEAD), next someone should invent sane defaults that actually work for a default installation. Next installer should autodetect or ask (during installation) if user wants to run on laptop-mode or not. And really, the only sane default for ubuntu would be hdparm -B 128, provided that laptop-mode is actually working as expected. Because as previously noted, shock protection is important.

Revision history for this message
Alexey Borzenkov (snaury) wrote :

Also, more on laptop-mode. In config file comments I've seen that it is disabled by default (and it seems devs tried to make it not so obvious how to really enable it), because it causes odd hangs on some computers. What sort of hangs are we dealing with? If this was about hangs when watching a movie, then the right answer would be not setting LM_READAHEAD to 3072 by default. It'd be a shame if laptop-mode was so hard-codedly disabled because of readahead problem. :-/

Revision history for this message
Bart Samwel (bart-samwel) wrote :

Alexey Borzenkov wrote:
> Also, more on laptop-mode. In config file comments I've seen that it is
> disabled by default (and it seems devs tried to make it not so obvious
> how to really enable it), because it causes odd hangs on some computers.
> What sort of hangs are we dealing with? If this was about hangs when
> watching a movie, then the right answer would be not setting
> LM_READAHEAD to 3072 by default. It'd be a shame if laptop-mode was so
> hard-codedly disabled because of readahead problem. :-/

These were hard system hangs on Thinkpads. :-(

Revision history for this message
Brendon Brewer (brendonbrewer) wrote :

Confirmed on HP Pavilion DV6614tx running Hardy.

I had a load cycle count of 114,000 in 6 months at an average of 93 per hour. The workaround posted above resolved the problem.

Revision history for this message
Noiano (noiano) wrote :

I have bought a new laptop and I have installed both ubuntu and fedora
core 9. On ubuntu I immediately installed the fix ( the one starting by
"if on power; then..") but on fedora I did not. I noticed a lots of
«clicks» using fedora and the number of head parkings increased. Is
Fedora Core affected by the same ubuntu bug? I fear so. If so could you
tell me if I can use the same fix?

Thanks

Noiano

Revision history for this message
Mark Baas (mark-baas123) wrote :

The same fix is the pm-utils fix (hardy), then yes you can use the same files.

Revision history for this message
Noiano (noiano) wrote :

Mark Baas wrote:
> The same fix is the pm-utils fix (hardy), then yes you can use the same
> files.

Begging your pardon I didn't not understand. On ubuntu I use this fix:

#!/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

That pm-utils you mentioned solves the problem better than this fix?

What about FC9?

Thanks again

Revision history for this message
Pacho Ramos (pacho) wrote :

I suggest you check:
https://bugzilla.novell.com/show_bug.cgi?id=386555

Seems that they are working on a solution

Revision history for this message
dimovnike (dimovnike) wrote :

Just checked my ACER Extensa 5210, I bought it 3 months ago (laptop run mostly on AC power)
Load_Cycle_Count 68629
Power_On_Hours 707
Seems like I have 97 cycles/hour - it seems too much for me, anyway I use thunderbird to check my email every 3 minutes, but it is still strange to have 97 cycles per hour. Now I disabled APM using hdparm and cycles stopped increasing. Really strange that developers don't care about such an important bug...

Revision history for this message
dimovnike (dimovnike) wrote :

I am also concerned about the cooler, it turns on every minute for 30 seconds then stops, this happens even if laptop is totally idle. Any ideas? Is it normal?

Revision history for this message
Mark Callaghan (mdcallag) wrote :

With Hardy Heron on a Dell Vostro 1400, Load_Cycle_Count was increasing 2-5 times per minute with AC and battery. Setting ENABLE_LAPTOP_MODE=true in /etc/default/acpi-support fixed that problem. /proc/sys/vm/laptop_mode was set to 2 prior to that. With the change, among other things the APM level for the disk (valued used for hdparm -B) is set to 1 on battery and 254 on AC. I am still watching the temp on AC to determine if 254 is OK. Priot to setting ENABLE_LAPTOP_MODE=true, I manually changed the APM level to 1 and 127, but that did not solve the problem.

Revision history for this message
dimovnike (dimovnike) wrote :

Interesting! Setting ENABLE_LAPTOP_MODE=true really helps, but not after start. On my ACER Extensa 5210 it helps after I unplug and plug back the AC cord. So just after the start (if laptop started on AC) it is just as before, but if you unplug the AC cord - the power management is beeing set to 1 (which is acceotble for running on battery) if you plug back the AC cord, APM is switched off. I;m going to write a startup script which changes APM settings on startup...

Revision history for this message
Åskar (olskar) wrote :

I have tried everything! I can NOT stop the problem by applying hdparm -B 255 (or 254) myself! What else is there to try? :( LoadCycleCount is 1000000+!

Revision history for this message
Christophe Mehay (goldy-goldenfish) wrote :

Actually, the only way to stop the problem on my laptop (airis N1212) is disable the acpi at boot (acpi=off in grub).

No problem with ac, only with battery.

Revision history for this message
Pacho Ramos (pacho) wrote :

Is fully disabling Power Manager really needed? Wouldn't it cause some problems related with overheat or short battery lifetime?

Seems that my hardrive is now using 128 value:
# hdparm -I /dev/sda | grep Advanced
        Advanced power management level: 128
           * Advanced Power Management feature set
# smartctl -a /dev/sda -d ata | grep Load
193 Load_Cycle_Count 0x0032 090 090 000 Old_age Always - 218785
# smartctl -a /dev/sda -d ata | grep Power
  9 Power_On_Seconds 0x0032 076 076 000 Old_age Always - 12338h+14m+13s
 12 Power_Cycle_Count 0x0032 099 099 000 Old_age Always - 5498
192 Power-Off_Retract_Count 0x0032 098 098 000 Old_age Always - 569

218785 doesn't seem a bad value, after reading "man hdparm":

       -B Set Advanced Power Management feature, if the drive supports it.
              A low value means aggressive power management and a high value
              means better performance. Possible settings range from values 1
              through 127 (which permit spin-down), and values 128 through 254
              (which do not permit spin-down). The highest degree of power
              management is attained with a setting of 1, and the highest I/O
              performance with a setting of 254. A value of 255 tells hdparm
              to disable Advanced Power Management altogether on the drive
              (not all drives support disabling it, but most do).

Power save should still being enabled. Could it be related with me using reiserfs instead of ext3 for / ? :-/

Revision history for this message
Jakob Unterwurzacher (jakobunt) wrote :

Suse ships some fix now (storage-fixup and storage-fixup.conf at the bottom of http://bugzilla.novell.com/show_bug.cgi?id=386555 )
They use a blacklist approach for disabling APM on affected drives, which seems reasonable.
The blacklist seems to be maintained by someone at <email address hidden> (see comments in storage-fixup.conf).

Looks quite good, what about including it in ubuntu?

Revision history for this message
pelm (pelle-ekh) wrote :

I have a Clevo laptop with a Samsung Harddisk. Ubuntu 8.04. I'm totally confused with this issue. My system have hdparm -B 254 and no Load_Cycle_Count, but my 'Load_Retry_Count' is constantly increasing. The clicks is loud, much louder than the clicks from Load_Cycle_Count increase. Sometimes the clicks comes often 2-3-4 clicks in short times and then stops for half an hour or so. The clicks is very bothering.
I have disabled tracker, no hddtemp in daemon mode, and i have mounted ext3 with noatime flag.
What is that 'Load_Retry_Count' clicks? What should i do to stop them, they are annoying.

Regards
pelm

Revision history for this message
Alexey Borzenkov (snaury) wrote :

Hi pelm,

I had an exactly the same issue with my Samsung drive, I suspect this could be happening because of overheating or some other hardware problem causing superclicks if heads are not parked for more than a minute or so. I'm tired of repeating that disabling power management is *not* a solution. Minimizing disk access is. And that's what laptop-mode is for.

Please see my comments:

https://bugs.launchpad.net/ubuntu/+source/acpi-support/+bug/59695/comments/476
https://bugs.launchpad.net/ubuntu/+source/acpi-support/+bug/59695/comments/487

As well as a recent bug report to fix laptop-mode not working on startup:

https://bugs.launchpad.net/ubuntu/+source/pm-utils/+bug/239419

I'm surprised that it works so well for me for so long (despite constantly fighting ubuntu "fixes") and yet there are no comments from developers or anyone else.

Revision history for this message
sibidiba (sibidiba) wrote :

I can not believe that it is normal for a basic, non-enterprise disk to overheat, not even when it is permanently used.
If disabling power management causes any other issue than decreased battery life by max. 5%, then this is obviously some disk/firmware related bug.

This is why I guess the blacklist approach mentioned by Jakob (https://bugs.launchpad.net/ubuntu/+source/acpi-support/+bug/59695/comments/515) is more straightforward.

Revision history for this message
houstonbofh (leesharp) wrote :

Gabor CZIGOLA wrote:
> I can not believe that it is normal for a basic, non-enterprise disk to overheat, not even when it is permanently used.
> If disabling power management causes any other issue than decreased battery life by max. 5%, then this is obviously some disk/firmware related bug.
>
> This is why I guess the blacklist approach mentioned by Jakob
> (https://bugs.launchpad.net/ubuntu/+source/acpi-
> support/+bug/59695/comments/515) is more straightforward.

I also like the Novel blacklist approach.

1) Does not change drives that play fair.
2) Fixes known bad actors.
3) Shames bad actors, and acts as a buying guide.

Revision history for this message
ceg (ceg) wrote :

A "howto get disks idleing correctly (without excessive load cycling)" has been added to:
https://wiki.ubuntu.com/PowerManagement

ceg (ceg)
description: updated
ceg (ceg)
description: updated
Revision history for this message
Vincenzo Ciancia (vincenzo-ml) wrote : Re: [Bug 59695] Re: High frequency of load/unload cycles on some hard disks may shorten lifetime

I have not followed the whole thread. Right after installing hardy, I
was about to send my laptop to repair because I was experiencing random
deadlocks with high temperature. Then after some upgrade the problem
vanished and indeed I had the symptoms of this bug.

So the question is:

has this bug been fixed in general for hardy, or are you actually saying
that every hardy user could burn his/her laptop disk if not going trough
the steps that the linked webpage mentions? Let's state it clearly since
in the latter case at least I will advice people that still didn't
upgrade not to use hardy until we are reasonably sure that we are not
going to damage their disk.

Revision history for this message
Ryan Waldroop (ryan.waldroop) wrote : Re: [Bug 59695] Re: High frequency of load/unload cycles on some hard disks may shorten lifetime

The problem is that this bug was definitely present in Gutsy, and possibly
Feisty. So telling someone not to upgrade won't necessarily help them. If
you are providing Tech Support for someone, I would say it is safe to
upgrade to Hardy, but you need to go ahead and check their load/unload
cycles using the tools mentioned in this thread, and if necessary, apply the
fixes posted here.

On Mon, Jul 7, 2008 at 7:26 AM, Vincenzo Ciancia <email address hidden>
wrote:
>
> Let's state it clearly since
> in the latter case at least I will advice people that still didn't
> upgrade not to use hardy until we are reasonably sure that we are not
> going to damage their disk.
>

Revision history for this message
Vincenzo Ciancia (vincenzo-ml) wrote : Re: [Bug 59695] Re: High frequency of load/unload cycles on some hard disks may shorten lifetime

Il giorno lun, 07/07/2008 alle 12.46 +0000, Ryan Waldroop ha scritto:
> if necessary, apply the
> fixes posted here.

Ok, thank you for the clarification. And the fact that I saw this fixed
by an upgrade on a laptop of my own does mean that some measures have
already been taken?

Revision history for this message
Åskar (olskar) wrote :

I see that Suse and Debian has released a fix for this, cant we use the same fix?

Revision history for this message
Daniel Bermudez G. (nergar) wrote :

I just got a new Dell laptop and I'm getting an average of 31 clicks per hour. Load_Cycle_Count / Power_On_Hours = 1706 / 55.

I just went to https://wiki.ubuntu.com/PowerManagement to try to fix this but the "How to get disks idleing correctly (without excessive load cycling)" part is everything but clear.

Why ask people not to use this as a support forum but don't provide a link to a support thread?

I'm using Suse until Ubuntu can get this sorted out. Maybe Ubuntu should use Suse's fix.

Revision history for this message
paulo_alex (paulo-alex-87) wrote :

the solution?

=> https://launchpad.net/~snaury/+archive (acpi-support - 0.110~df1)

one Alexey Borzenkov's patch

Revision history for this message
Alexey Borzenkov (snaury) wrote :

paulo_alex, no, that's not the solution (all it does is lets other packages do their jobs). For first steps to solution see bug 250935 and bug 250938.

Revision history for this message
Mikko Ohtamaa (mikko-red-innovation) wrote :

I followed instructions at https://wiki.ubuntu.com/PowerManagement

I had been using a new laptop for few days:

root@hereford:~# smartctl -a /dev/sda -d ata
...
=== START OF INFORMATION SECTION ===
193 Load_Cycle_Count 0x0032 099 099 000 Old_age Always - 16266

A very high number for such a short time! Load cycles were raising few cycles per minute which was very very aggressive. Luckily ceg's PowerManagement instructions provided a proper workaround and Load_Cycle_Count stopped increasing.

Revision history for this message
paulo_alex (paulo-alex-87) wrote :

Alexey,

these bugs was resolved, then this bug too, no?

Revision history for this message
Alexey Borzenkov (snaury) wrote :

No, because laptop-mode is still disabled by default. If you experience these problems (big note: this is currently for intrepid only!) you can try the following:

Edit /etc/default/acpi-support: ENABLE_LAPTOP_MODE=true
Edit /etc/laptop-mode/laptop-mode.conf: BATT_HD_POWERMGMT=number and NOLM_AC_HD_POWERMGMT=number (if you still experience problems with now default 1 and 254)

The bugs that were finally resolved just make such changes very easy to do for everyone (a very simple config file), that they actually work and ensure these changes are reapplied after suspend/resume hibernate/thaw.

Revision history for this message
ceg (ceg) wrote :

Hi,
https://wiki.ubuntu.com/PowerManagement has been updated to respect the fixes for intrepid (ubuntu 8.10).

You currently still need to follow the steps mentioned there for hardy (ubuntu 8.04) installs.

(I guess Vincenzo Ciancia who reported his issues where fixed with recent hardy updates experienced a different bug.)

Revision history for this message
Endolith (endolith) wrote :

So 56 load cycles per hour would be a bad number?

Model Family: Hitachi Travelstar 7K100
Device Model: Hitachi HTS721010G9AT00
Dell Inspiron 8600
Ubuntu 8.04

In November, I was told by Ubuntu Forum staff that I didn't have to worry about this, since laptop mode is disabled by default and I don't have it installed. Was I told wrong?

If your product is destroying users' hardware, this should be a TOP priority for fixing. If you're not going to fix it, the very least you could do is include a script that checks for inordinate numbers of load cycles, warns the user, and points them to ways to fix it. An obscure link to a confusing wiki page is not good enough.

Revision history for this message
Vincenzo Ciancia (vincenzo-ml) wrote :

Il giorno mer, 20/08/2008 alle 03.48 +0000, Endolith ha scritto:
>
> If your product is destroying users' hardware, this should be a TOP
> priority for fixing. If you're not going to fix it, the very least
> you
> could do is include a script that checks for inordinate numbers of
> load
> cycles, warns the user, and points them to ways to fix it. An obscure
> link to a confusing wiki page is not good enough.

Yes please, a script that checks if the problem is present should really
be added to hardy and intrepid, so to avoid very bad publicity in case
of a spread of broken disks caused by ubuntu.

Vincenzo

Revision history for this message
Pascal Vandeputte (pascal-vdp) wrote :

I'm highly in favor of the blacklist approach used by Novell/openSUSE as well. It tracks different laptop/hard disk combinations and knows exactly which apm value (254/255) fixes the problem for each entry. The storage-fixup script was written and is maintained by kernel developer Tejun Heo by the way, you can read more information and find the latest version of the script and config file at http://ata.wiki.kernel.org/index.php/Known_issues

If your drive isn't listed yet, you can add the config yourself by looking at the examples and comparing with the output of "dmidecode", "hdparm -I /dev/sda" and "smartctl -a /dev/sda" on your system. You're encouraged to send Tejun Heo this information and whether hdparm -B 254/255 fixes it, so the drive db gets more and more complete. You can do this by mailing <email address hidden> like I did here: http://marc.info/?l=linux-ide&m=122082089712147&w=2

This way regular users won't need to use trial and error to see which apm value is needed to disable it.

Revision history for this message
Vincenzo Ciancia (vincenzo-ml) wrote :

I am now testing intrepid and even tough I don't have deadlocks, the bug is there, load cycles increase. Was this a bug also in previous releases? Is it also a bug in windows?

Revision history for this message
Ryan Waldroop (ryan.waldroop) wrote : Re: [Bug 59695] Re: High frequency of load/unload cycles on some hard disks may shorten lifetime

I definitely experienced this bug with my laptop in Gutsy. Some people may
have had this problem in Feisty as well.

The bug is also *technically* present in Windows...except Windows is too
busy constantly polling the hard disk to let it idle even for a second.

On Thu, Sep 25, 2008 at 4:24 AM, Vincenzo Ciancia <email address hidden>wrote:

> I am now testing intrepid and even tough I don't have deadlocks, the bug
> is there, load cycles increase. Was this a bug also in previous
> releases? Is it also a bug in windows?

Revision history for this message
peter_ger (klaus-viertel) wrote :

The workaround on https://wiki.ubuntu.com/PowerManagement plus the correction of the FOR statement in power.sh mentioned here https://bugs.launchpad.net/ubuntu/+source/acpi-support/+bug/89269 finally works here :D

No cycles for 1h now!

Using Ubuntu 8.04.1 on a T42 with Hitachi HDD

Revision history for this message
Endolith (endolith) wrote :

Are we supposed to be looking at load cycle count or start/stop count? My load cycles are about 200 per hour lately, but http://ata.wiki.kernel.org/index.php/Known_issues says "Start_Stop_Count", which I also have.

Revision history for this message
Johnny Levai (digistyl3) wrote :

Yes, it IS pesent in Windows too. Just checked it in Vista SP1, and not only with my ears, but also with smartmontools and hdparm for Windows. Vista does the same as Ubuntu: nothing... it just let's the hdd manage itself. I fixed it in Linux with setting hdparm to 254 while on AC mode and 128 while on battery mode. I also installed "ramlog", so it's performing very nicely :) Actually the only thing killing my hdd right now is Vista. But updates are coming with acpi-support to do the hdparm thing automatically.

Revision history for this message
Ryan Waldroop (ryan.waldroop) wrote :

I just (finally) upgraded to Intrepid on my IBM T41 laptop. I went like 10
minutes without any LOAD_CYCLE_COUNT increases, and thought this had
actually been fixed. Then I checked again 5 minutes later and it jumped up
by 17. Now I'm looking at a steady 3-4 load cycles per minute on battery,
and about the same on AC power.

I guess Ubuntu still hasn't included the Debian fix? Is testing still
inconclusive on that? I've been using the fixes listed here for almost a
year and haven't noticed any over heating. I think it's time to include
this fix. IMO, hard drives are more likely to be harmed by excessive load
cycling than by the extra 1 degree of heat or anything else. Also, it looks
like my heads are only staying parked for a few seconds at most. What are
the chances that my hard drive (A) will actually be parked if drop my laptop
or (B) be protected even if it is parked?

Revision history for this message
Chow Loong Jin (hyperair) wrote : Re: [Bug 59695] Re: High frequency of load/unload cycles on some hard disks may shorten lifetime

On Sat, 2008-10-04 at 15:01 +0000, Ryan Waldroop wrote:
> I just (finally) upgraded to Intrepid on my IBM T41 laptop. I went like 10
> minutes without any LOAD_CYCLE_COUNT increases, and thought this had
> actually been fixed. Then I checked again 5 minutes later and it jumped up
> by 17. Now I'm looking at a steady 3-4 load cycles per minute on battery,
> and about the same on AC power.
>
> I guess Ubuntu still hasn't included the Debian fix? Is testing still
> inconclusive on that? I've been using the fixes listed here for almost a
> year and haven't noticed any over heating. I think it's time to include
> this fix. IMO, hard drives are more likely to be harmed by excessive load
> cycling than by the extra 1 degree of heat or anything else. Also, it looks
> like my heads are only staying parked for a few seconds at most. What are
> the chances that my hard drive (A) will actually be parked if drop my laptop
> or (B) be protected even if it is parked?
>
(A) Depends on your disk activity.
(B) If you drop it while the disk head is parked, the hard disk will
definitely withstand a significant amount of impact more than it would
withstand if it wasn't parked.
--
Chow Loong Jin

Revision history for this message
Colin Watson (cjwatson) wrote :

I believe all the necessary fixes (well, the workaround for the major parts of this bug) are included now in Intrepid. Here are the changelogs:

acpi-support (0.111) intrepid; urgency=low

  * lib/IBM.config: Change VBE state and POST_VIDEO for 1834's
    (LP: #40621, #211285)
  * Incorporate a portion of the changes from Debian, as detailed below.
    Debian has been accumulating valuable fixes and structural changes for
    some years, but it will take some time to digest all of them.

  [ Bart Samwel ]
  * ac.d/90-hdparm.sh, battery.d/90-hdparm.sh, resume.d/90-hdparm.sh,
    start.d/90-hdparm.sh: Set hdparm power management to 254 for all hard
    drives. Ignore errors while detecting of APM is supported. Set
    hdparm -B 128 while on battery in 90-hdparm.sh. Head parking is useful
    on the road for shock protection. Still set hdparm -B 254 while on AC.
    (Closes: #448673, #452489, #453478, #458787, #481685)
  * Switch from #!/bin/bash to #!/bin/sh in a number of scripts, and
    cleanup bashisms throughout. Continues a change started with 0.93.
    (Closes: #407510, #485435, #453861)
  * Add checks for existance of key-constants and state-funcs throughout
    scripts to prevent erroneous failures when using eeepc-acpi-scripts.
    Use "test ... || ..." style over "[ ... ] || ..." just for consistency.
    (Closes: #469556)
  * Check if we can actually open event device in acpi_fakekey.c.
    (Closes: #410478)
  * Correctly detect keyboard event device in acpi_fakekey.c. Apparently
    the power key is in the range checked by acpi_fakekey. It's now
    changed it so that it assumes that any input device which has a key in
    the QWERTYUIOP range is "the" keyboard.
    (Closes: #433771)
  * Remove useless use of grep in asus-touchpad.sh.
  * Add HOTK key names in events/asus-* for additional keys.
  * Support Asus Eee PC volume up/down and mute keys in events/asus-eee-volume-*.
    (Closes: #459326)
  * Add rotatescreen.sh, asus-rotate script to support Asus R1F tablet
    screen rotation.
    (Closes: #450531)

  [ Raphael Hertzog ]
  * Add a new SKIP_INTERFACES variables in /etc/default/acpi-support and use
    it to define network interfaces that are not tied to hardware to avoid
    shutting them down during suspend, such as lo, qemu, and dummy.
  * Improved package description in control file, thanks to Cl?ment Stenac.
    (Closes: #383691)

  [ Loic Minier ]
  * Install new manpage for acpi_fakekey, thanks Nico Golde.
    (Closes: #383365)
  * Fix "APCI" instead of "ACPI" typo in IBM.config; thanks Joshua Kwan;
    (Closes: #389511)

 -- Bryce Harrington <email address hidden> Wed, 24 Sep 2008 08:43:42 -0700

laptop-mode-tools (1.45-1ubuntu2) intrepid; urgency=low

  * etc/laptop-mode/laptop-mode.conf: Go back to 'hdparm -B 254';
    acpi-support has been fixed to do that now, so let's not have
    laptop-mode-tools undo the effectiveness of that fix in the name of
    consistency with an old version (LP: #172282).

 -- Colin Watson <email address hidden> Wed, 08 Oct 2008 15:05:10 +0100

Changed in acpi-support:
status: Triaged → Fix Released
Revision history for this message
Felipe Figueiredo (philsf) wrote :

@Colin,

thanks for that. Could you (or anyone) summarize what's *not* fixed/worked around in this release? Thinking of a fresh intrepid install, what's left for the user to do?

Revision history for this message
Vincenzo Ciancia (vincenzo-ml) wrote :

Il giorno mer, 08/10/2008 alle 14.44 +0000, Felipe Figueiredo ha
scritto:
>
>
> thanks for that. Could you (or anyone) summarize what's *not*
> fixed/worked around in this release? Thinking of a fresh intrepid
> install, what's left for the user to do?

Please also state in which daily image the fix will appear: I have to
reinstall my hardy beta and would like to be sure to catch the fix from
the beginning.

Vincenzo

Revision history for this message
Ryan Waldroop (ryan.waldroop) wrote : Re: [Bug 59695] Re: High frequency of load/unload cycles on some hard disks may shorten lifetime

@ Felipe:

Actually, with further testing, my laptop appears to be fixed while on AC
power, but it's still cycling a lot on battery. The wiki page linked in the
opening bug post has a three step process to check if everything is fixed
and change the values if you like. For me, I didn't want everything set to
255, so I set both AC and Battery to 254. This seems to be working well for
me.

Good luck!

Revision history for this message
Colin Watson (cjwatson) wrote :

Vincenzo: tomorrow's provided that the build succeeds. However there's never a guarantee of that with daily builds. Check the version numbers in the .list/.manifest files.

Changed in acpi-support:
importance: Undecided → Critical
milestone: none → ubuntu-8.04.2
status: New → Triaged
Revision history for this message
Bart Samwel (bart-samwel) wrote : Re: [Bug 59695] Re: High frequency of load/unload cycles on some hard disks may shorten lifetime

Ryan Waldroop wrote:
> @ Felipe:
>
> Actually, with further testing, my laptop appears to be fixed while on AC
> power, but it's still cycling a lot on battery. The wiki page linked in the
> opening bug post has a three step process to check if everything is fixed
> and change the values if you like. For me, I didn't want everything set to
> 255, so I set both AC and Battery to 254. This seems to be working well for
> me.

The fix that has now been applied is the Debian fix, which purposely
leaves the power management (and therefore the cycling) enabled when the
laptop is working on battery. This is for safety reasons: it is assumed
that the laptop is working on battery when it is being carried around,
and it is much safer to park the heads in such situations. Also, we did
not want to increase the power usage while in battery mode! This does
mean that the drive lifetime still becomes shorter, but since
battery-mode usage is limited by battery life span, required recharge
times, and general usage patterns, this is already a much safer
situation. (This is, however, not configurable. If you want that,
install laptop-mode-tools and let that handle it. The acpi-support fix
detects if laptop-mode-tools handles it, and leaves it to
laptop-mode-tools in that case.)

Cheers,
Bart

Revision history for this message
Przemek K. (azrael) wrote :

Why is acpi-support still used in Intrepid? Shouldn't Ubuntu use pm-utils only by now?

Revision history for this message
Bart Samwel (bart-samwel) wrote :

Przemysław Kulczycki wrote:
> Why is acpi-support still used in Intrepid? Shouldn't Ubuntu use pm-
> utils only by now?

The acpi-support package has two functions. One is suspend, the other is
to translate hardware specific events into generic ones (such as custom
keys). I'm considering a functional split in Debian, but that's
postponed until after the Lenny release.

BTW, the Debian package deprecates the acpi-support suspend code in
favour of pm-utils. The Ubuntu version still uses its own suspend code,
but the config file incorrectly advertises the new Debian functionality.
Perhaps someone should report it as a bug? I should probably do it myself...

Revision history for this message
zombiepig (nyall-zombiepigs) wrote :

On my acer extensa 5620, the latest updates have fixed most of the hardy drive cycling problems, HOWEVER, when I suspend then resume, I'm still get excessive cycling on both battery and power. This only seems to be triggered after resuming...

Revision history for this message
Bart Rose (jbrose3) wrote :

My thinkpad R52 under intrepid beta is not utilising the 90-hdparm.sh scripts and instead is getting it's parameters from laptop-mode.conf. Interestingly BATT_HD_POWERMGMT in laptop-mode.conf is set to a value of 1 by default and not 128. Is this a typo? After changing it to 128, everything seems to be working like a charm.

Revision history for this message
Hernando Torque (htorque) wrote :

I can confirm this still is a problem when resuming from standby - APM-level reset to 128 and load cycles going up again like crazy.

Revision history for this message
Hernando Torque (htorque) wrote :

Fixed it with a modified version of the already mentioned SUSE pm-script - took like 3 minutes to write...

Revision history for this message
Artur Rona (ari-tczew) wrote :

So this bug officially has been fixed in Ubuntu Intrepid 8.10?

Revision history for this message
Eric Drechsel (ericdrex) wrote :

I'm still having the frequent load cycle problem with an up to date Intrepid, so no. Hernando, will this fix be included in Intrepid?

Revision history for this message
Eric Drechsel (ericdrex) wrote :

Enabling laptop mode as in https://wiki.ubuntu.com/PowerManagement fixes this for me in Intrepid, so I guess it's working!

I guess laptop mode should be enabled by default?

Revision history for this message
Hernando Torque (htorque) wrote :

@Eric: I'm sorry for not being clear - I ment I fixed it locally on my laptop by following the workarounds for SUSE (using a pm-script to set the hdparm value).

Revision history for this message
Vincenzo Ciancia (vincenzo-ml) wrote :

I enabled laptop mode in intrepid but when I am on battery power I get 120 load cycles per hour...

Revision history for this message
Darlan Cavalcante (darcamo) wrote :

I also enabled laptop-mode and and the bug was there on battery.
In laptop-mode config file it says that hdparm uses -B254 when on AC and -B1 when on battery.

I changed -B1 to -B128 but the load_cycles still increase rapidly (I tested higher values with hdparm, but even higher values such as -B230 does not solve the problem for me - only -B254 or -B255).

Shouldn't laptop-mode make reads and writes less frequently? If laptop-mode avoids accessing the HD for about 3 minutes average the problem would be solved and the "parking feature" of the HDs would actually be a feature instead of a problem.

While -B254 stop the load cycle problem I don't feel comfortable with this as a solution since the temperature jumps from 40-42 (Vista) to 48-49 (ubuntu with -B254) when in normal usage.

Notice that if i use -B128 and keep the HD busy (downloads, for instance) the temperature stays in the range 39-40 and the load cycle does not increase -> by the same reason it is not using the "parking feature" for impact protection.

Therefore, the perfectly solution would be if laptop-mode could really stop any access to the hard drive for 2 or 3 minutes (average) avoiding the excessive load cycle while at the same time using the park feature of the HD for protection.

On the other hand, ubuntu could constantly pool the hard drive to avoid a load cycle and use a value such as 128 for hdparm (at least while a better solution with laptop-mode is found). While there wouldn't be the protection provided by parking, at least it would avoid increasing the HD temperature unnecessarily. This seems to be what Vista does (intentionally or unintentionally), since I see the HD light blink periodically even when It is idle.

Revision history for this message
ASDFASDF (user-487-deactivatedaccount) wrote :

I am still affected by this bug in the fresh install of Intrepid RC, this bug is not fixed!
Hdparm reports: Advanced power management level: 128
Laptop is plugged in AC (it's HP 6710b)... I'm back to 99-hdd-ugly-fix

Revision history for this message
thebrotherofasis (libardoab) wrote : Re: [Bug 59695] Re: High frequency of load/unload cycles on some hard disks may shorten lifetime

Thanks for the info,

I have a hp dv6645us, running the ugly fix in 8.04, and I think I will stay
with it until april 09, to see if it's really fixed then.

Many people have reported this is not fixed, as opposed to what they say in
launchpad.

On Mon, Oct 27, 2008 at 10:42 AM, Igor Vatavuk <email address hidden>wrote:

> I am still affected by this bug in the fresh install of Intrepid RC, this
> bug is not fixed!
> Hdparm reports: Advanced power management level: 128
> Laptop is plugged in AC (it's HP 6710b)... I'm back to 99-hdd-ugly-fix
>
> --
> High frequency of load/unload cycles on some hard disks may shorten
> lifetime
> https://bugs.launchpad.net/bugs/59695
> You received this bug notification because you are a direct subscriber
> of a duplicate bug.
>

Revision history for this message
Babyshamble (babyshamble) wrote :
Download full text (6.5 KiB)

I got it fixed in a HP 6720b with a fresh install of Intrepid and with
laptop_mode on acpi properties. Did you enable it?

On Mon, Oct 27, 2008 at 1:42 PM, Igor Vatavuk <email address hidden>wrote:

> I am still affected by this bug in the fresh install of Intrepid RC, this
> bug is not fixed!
> Hdparm reports: Advanced power management level: 128
> Laptop is plugged in AC (it's HP 6710b)... I'm back to 99-hdd-ugly-fix
>
> --
> High frequency of load/unload cycles on some hard disks may shorten
> lifetime
> https://bugs.launchpad.net/bugs/59695
> You received this bug notification because you are a direct subscriber
> of the bug.
>
> Status in The Dell Project: Confirmed
> Status in "acpi-support" source package in Ubuntu: Fix Released
> Status in "linux-meta" source package in Ubuntu: New
> Status in "pm-utils" source package in Ubuntu: New
> Status in acpi-support in Ubuntu Hardy: Triaged
> Status in linux-meta in Ubuntu Hardy: New
> Status in pm-utils in Ubuntu Hardy: New
> Status in "acpi-support" source package in Baltix: New
> Status in "acpi-support" source package in Debian: Fix Released
> Status in "pm-utils" source package in Fedora: Invalid
> Status in "laptop-mode-tools" source package in Mandriva: Confirmed
> Status in Suse Linux: Fix Released
>
> Bug description:
> This is not a support forum. Please do not use it as such (even though it
> has been used as such already).
>
> You can scan through the bug for links to the Ubuntu forums where many,
> many different questions have been asked, answered, and re-answered. The
> temporary workaround is just below.
>
> See https://wiki.ubuntu.com/PowerManagement for an overview about what is
> involved and for a remedy.
>
>
> Following is a summary of the issue:
> It is confirmed that some systems are seeing an unusually high number of
> load/unload cycles on their hard disks, as evidenced by smartctl.
>
> It was originally surmised that this was related to laptop-mode being
> enabled, but this especially affects systems where laptop-mode is disabled.
> In fact, aggressive APM is not a bad idea while a system is not on AC, as
> that system is much more likely to encounter a physical impact.
>
> This is due to disk APM settings that let the heads park or disk spin down
> after an idle period that is shorter than the regular disk access patterns
> of the OS.
>
> Then, the heads are only parked for a very short period of time and almost
> imediately loaded again. Making impact protection much ineffective and
> wearing out the drive.
>
> It can happen when the disk asumes aggressive APM settings (like many
> laptop disks) and the OS does not take care to set the APM settings
> accordingly to its current disk access pattern.
>
> This problem has been confirmed in Ubuntu as well as in other distributions
> and on MacOS X and Windows.
>
> Symptoms of this bug are:
> * Frequent HD clicks -- more than one per 3 minutes while idle, louder
> than the typical access sounds. Often more than twice per minute. On some
> disks, the click is very quiet
> * Rapidly Increasing Load_Cycle_Count as displayed in the final number in
> "sudo smartctl -a /dev/hda | grep Load_Cycle_Count" (where /dev/hd...

Read more...

Revision history for this message
thebrotherofasis (libardoab) wrote :
Download full text (7.2 KiB)

Did it fix it even after suspending / hibernating on battery?

On Mon, Oct 27, 2008 at 2:11 PM, Babyshamble <email address hidden>wrote:

> I got it fixed in a HP 6720b with a fresh install of Intrepid and with
> laptop_mode on acpi properties. Did you enable it?
>
> On Mon, Oct 27, 2008 at 1:42 PM, Igor Vatavuk
> <email address hidden>wrote:
>
> > I am still affected by this bug in the fresh install of Intrepid RC, this
> > bug is not fixed!
> > Hdparm reports: Advanced power management level: 128
> > Laptop is plugged in AC (it's HP 6710b)... I'm back to 99-hdd-ugly-fix
> >
> > --
> > High frequency of load/unload cycles on some hard disks may shorten
> > lifetime
> > https://bugs.launchpad.net/bugs/59695
> > You received this bug notification because you are a direct subscriber
> > of the bug.
> >
> > Status in The Dell Project: Confirmed
> > Status in "acpi-support" source package in Ubuntu: Fix Released
> > Status in "linux-meta" source package in Ubuntu: New
> > Status in "pm-utils" source package in Ubuntu: New
> > Status in acpi-support in Ubuntu Hardy: Triaged
> > Status in linux-meta in Ubuntu Hardy: New
> > Status in pm-utils in Ubuntu Hardy: New
> > Status in "acpi-support" source package in Baltix: New
> > Status in "acpi-support" source package in Debian: Fix Released
> > Status in "pm-utils" source package in Fedora: Invalid
> > Status in "laptop-mode-tools" source package in Mandriva: Confirmed
> > Status in Suse Linux: Fix Released
> >
> > Bug description:
> > This is not a support forum. Please do not use it as such (even though
> it
> > has been used as such already).
> >
> > You can scan through the bug for links to the Ubuntu forums where many,
> > many different questions have been asked, answered, and re-answered. The
> > temporary workaround is just below.
> >
> > See https://wiki.ubuntu.com/PowerManagement for an overview about what
> is
> > involved and for a remedy.
> >
> >
> > Following is a summary of the issue:
> > It is confirmed that some systems are seeing an unusually high number of
> > load/unload cycles on their hard disks, as evidenced by smartctl.
> >
> > It was originally surmised that this was related to laptop-mode being
> > enabled, but this especially affects systems where laptop-mode is
> disabled.
> > In fact, aggressive APM is not a bad idea while a system is not on AC,
> as
> > that system is much more likely to encounter a physical impact.
> >
> > This is due to disk APM settings that let the heads park or disk spin
> down
> > after an idle period that is shorter than the regular disk access
> patterns
> > of the OS.
> >
> > Then, the heads are only parked for a very short period of time and
> almost
> > imediately loaded again. Making impact protection much ineffective and
> > wearing out the drive.
> >
> > It can happen when the disk asumes aggressive APM settings (like many
> > laptop disks) and the OS does not take care to set the APM settings
> > accordingly to its current disk access pattern.
> >
> > This problem has been confirmed in Ubuntu as well as in other
> distributions
> > and on MacOS X and Windows.
> >
> > Symptoms of this bug are:
> > * Frequent HD clicks -- more ...

Read more...

Revision history for this message
ASDFASDF (user-487-deactivatedaccount) wrote :

I didn't try laptop-mode but I shouldn't have to, the fix was for acpi-support, hdparm should be 254 while laptop is on AC.

quote:
acpi-support (0.111) intrepid; urgency=low
  * ac.d/90-hdparm.sh, battery.d/90-hdparm.sh, resume.d/90-hdparm.sh,
    start.d/90-hdparm.sh: Set hdparm power management to 254 for all hard
    drives. Ignore errors while detecting of APM is supported. Set
    hdparm -B 128 while on battery in 90-hdparm.sh. Head parking is useful
    on the road for shock protection. Still set hdparm -B 254 while on AC.
    (Closes: #448673, #452489, #453478, #458787, #481685)

Revision history for this message
Marco Scholl (traxanos) wrote :

I have the XPS1300. The Problem isn't solved.
I use Ubuntu Intrepid with all updates.

Revision history for this message
Ciso (cisoprogressivo) wrote :

Same problem with my Dell XPS M1330.
In windows it works good :(

Revision history for this message
Babyshamble (babyshamble) wrote :
Download full text (6.3 KiB)

Confirmed to be fixed with AC power but not with Battery
Notebook HP 6720s

On Mon, Oct 27, 2008 at 9:20 PM, Ciso <email address hidden> wrote:

> Same problem with my Dell XPS M1330.
> In windows it works good :(
>
> --
> High frequency of load/unload cycles on some hard disks may shorten
> lifetime
> https://bugs.launchpad.net/bugs/59695
> You received this bug notification because you are a direct subscriber
> of the bug.
>
> Status in The Dell Project: Confirmed
> Status in "acpi-support" source package in Ubuntu: Fix Released
> Status in "linux-meta" source package in Ubuntu: New
> Status in "pm-utils" source package in Ubuntu: New
> Status in acpi-support in Ubuntu Hardy: Triaged
> Status in linux-meta in Ubuntu Hardy: New
> Status in pm-utils in Ubuntu Hardy: New
> Status in "acpi-support" source package in Baltix: New
> Status in "acpi-support" source package in Debian: Fix Released
> Status in "pm-utils" source package in Fedora: Invalid
> Status in "laptop-mode-tools" source package in Mandriva: Confirmed
> Status in Suse Linux: Fix Released
>
> Bug description:
> This is not a support forum. Please do not use it as such (even though it
> has been used as such already).
>
> You can scan through the bug for links to the Ubuntu forums where many,
> many different questions have been asked, answered, and re-answered. The
> temporary workaround is just below.
>
> See https://wiki.ubuntu.com/PowerManagement for an overview about what is
> involved and for a remedy.
>
>
> Following is a summary of the issue:
> It is confirmed that some systems are seeing an unusually high number of
> load/unload cycles on their hard disks, as evidenced by smartctl.
>
> It was originally surmised that this was related to laptop-mode being
> enabled, but this especially affects systems where laptop-mode is disabled.
> In fact, aggressive APM is not a bad idea while a system is not on AC, as
> that system is much more likely to encounter a physical impact.
>
> This is due to disk APM settings that let the heads park or disk spin down
> after an idle period that is shorter than the regular disk access patterns
> of the OS.
>
> Then, the heads are only parked for a very short period of time and almost
> imediately loaded again. Making impact protection much ineffective and
> wearing out the drive.
>
> It can happen when the disk asumes aggressive APM settings (like many
> laptop disks) and the OS does not take care to set the APM settings
> accordingly to its current disk access pattern.
>
> This problem has been confirmed in Ubuntu as well as in other distributions
> and on MacOS X and Windows.
>
> Symptoms of this bug are:
> * Frequent HD clicks -- more than one per 3 minutes while idle, louder
> than the typical access sounds. Often more than twice per minute. On some
> disks, the click is very quiet
> * Rapidly Increasing Load_Cycle_Count as displayed in the final number in
> "sudo smartctl -a /dev/hda | grep Load_Cycle_Count" (where /dev/hda is
> replaced with your own hard disk device)
> * Early hard disk failure never stay parked, due to very frequent disk
> activity. Thus this cycle occurs often, thus wearing out the drive, and any
> comparative be...

Read more...

Revision history for this message
sibidiba (sibidiba) wrote :

It is not a bug, it is a feature, when running on batteries.

Revision history for this message
Bart Rose (jbrose3) wrote :

Has anyone still having problems tried changing the value of BATT_HD_POWERMGMT in /etc/laptop-mode/laptop-mode.conf from 1 to 128? This seemed to have worked for me.

Revision history for this message
Hernando Torque (htorque) wrote :

@sibidiba:

Sure, load cycles aren't a bad thing, but at a value of 128 I had 10 of them per minute - that's too much. I can go without a feature that kills my disk.

Life time in load cycles: 600.000, warranty: three years, doing the math: 200.000 load cycles a year, 548 a day. After running one hour with a value of 128 my disk would have consumed the load cycles of a whole day. Make it three hours a day and the drive's expected life time would be a year.

Revision history for this message
sibidiba (sibidiba) wrote :

@Hernando:

Please read also previous comments, it is repetitively stated, that up to 15 load cycles per hour is OK anyway.

Also note that my comment was for "running on batteries". Indeed, high (>15/h) load cycles save power and may prevent data loss when dropped. But it can not damage your disk in this case, because you simply can't run long enough on batteries for this to happen...

Revision history for this message
Hernando Torque (htorque) wrote :

Pls reread. When running on batteries I get 600 load cycles per hour, not "up to 15". That's not acceptable as it will shorten life time (see second paragraph).

I just wanted to make it clear that this bug hasn't been fixed in a satisfying way for everyone.

Revision history for this message
Isaac Dupree (idupree) wrote :

what a mess. re: "you simply can't run long enough on batteries for this to happen", well, it's easy to. Unplug your computer, use it for three hours wherever, then suspend/shut it down/ignore it and plug it back in for a while to recharge, then repeat. Do this every day. It's easy to have a habit of almost always running on battery.

P.S. personally "plugged in" is not a good match for "not in danger" -- even when plugged in, my computer can often easily slip out of my lap, but sometimes I run not-plugged-in on the top of a stable desk. So I have a bit of an issue with using "on battery" to mean "likely to be dropped while being used" (if it's not being actively used, then I'm guessing there probably will not be much disk activity so the disk/head might as well be parked anyway?)

Revision history for this message
Endolith (endolith) wrote :

> So I have a bit of an issue with using "on battery" to mean "likely to be dropped while being used"

Yes, this is a silly assumption. My laptop is plugged in 99% of the time I am using it, but it is just as likely to be dropped as any other time. Even if it's parking often, what are the chances that it will be parked at the moment it is dropped anyway?

Revision history for this message
houstonbofh (leesharp) wrote : Re: High frequency of load/unload cycles on some hard disks may shorten lifetime

Endolith wrote:
>> So I have a bit of an issue with using "on battery" to mean "likely to
> be dropped while being used"
>
> Yes, this is a silly assumption. My laptop is plugged in 99% of the
> time I am using it, but it is just as likely to be dropped as any other
> time. Even if it's parking often, what are the chances that it will be
> parked at the moment it is dropped anyway?

This should be user-definable. I have never "droped" a laptop and lost
a drive, even when walking down a hall or up a ladder. I have, however,
banged a keyboard in frustration and lost a hard drive. The computer
was plugged in at the time... :)

Revision history for this message
Ryan Waldroop (ryan.waldroop) wrote : Re: [Bug 59695] Re: High frequency of load/unload cycles on some hard disks may shorten lifetime

It's all user definable, as described in this thread. I personally have
mine set at 254 whether it's on AC or not, and my battery life/temperature
is doing fine.

Revision history for this message
ASDFASDF (user-487-deactivatedaccount) wrote :

I just noticed after the restart that APM is 254 but after resuming from suspend it resets to 128. All this time I am on AC.
I apologize for the wrong information earlier, but nevertheless the issue still exists as notebooks are very often put in suspend.

Revision history for this message
ASDFASDF (user-487-deactivatedaccount) wrote :

The fix (90-hdparm.sh) doesn't work because by default there is a value in laptop-mode.conf
CONTROL_HD_POWERMGMT=1

Which renders the acpi script useless.

if [ "$LMT_CONTROL_HD_POWERMGMT" != 0 ] ; then
# Laptop mode controls hdparm -B settings, we don't.
DO_HDPARM=n
fi

This is in clean Intrepid install. Anyway, I set the CONTROL_HD_POWERMGMT to 0 and the script works if run manually but it still doesn't run automatically when resuming.
Anyone got the script to run on resume from suspend?

Revision history for this message
Milan Bouchet-Valat (nalimilan) wrote :

Igor: AFAIK, laptop-mode is not enabled by default. You need to tweak /etc/laptop-mode/laptop-mode.conf and switch the ENABLE_LAPTOP_MODE_ON_BATTERY option so that CONTROL_HD_POWERMGMT=1 really takes effect. So the bug does not come from here.

Revision history for this message
Bart Samwel (bart-samwel) wrote : Re: [Bug 59695] Re: High frequency of load/unload cycles on some hard disks may shorten lifetime

Milan wrote:
> Igor: AFAIK, laptop-mode is not enabled by default. You need to tweak
> /etc/laptop-mode/laptop-mode.conf and switch the
> ENABLE_LAPTOP_MODE_ON_BATTERY option so that CONTROL_HD_POWERMGMT=1
> really takes effect. So the bug does not come from here.

The problem is that the acpi-support code does not check if laptop mode
is enabled or not. It ALWAYS disables the check if
CONTROL_HD_POWERMGMT=1, even if ENABLE_LAPTOP_MODE=false in
/etc/default/acpi-support. The reason for this is that in Debian (from
which this fix was ported), the ENABLE_LAPTOP_MODE setting does not
exist. The check in acpi-support should be adapted to also take
ENABLE_LAPTOP_MODE into account.

Cheers,
Bart

Revision history for this message
ASDFASDF (user-487-deactivatedaccount) wrote :

You are right Bart, this needs to be fixed in the acpi-support script.
Another thing - resume.d scripts do not get executed on resume, we need a copy of the script in /etc/pm/sleep.d/
See bug #244839

Changed in dell:
importance: Undecided → Low
Revision history for this message
angel chen (angelchen1111) wrote :

How come in the file

DO_HDPARM=y
if [ -e /usr/sbin/laptop_mode ] ; then

it checks if the file /usr/sbin/laptop_mode exists rather than laptop mode is enabled? the file /usr/sbin/laptop_mode is always there even if laptop mode tool is not enabled. There is supposed to be other way to heck if laptop mode is enabled instead.

Anyways why does ubuntu still use ENABLE_LAPTOP_MODE to control laptop mode, debian has removed it long time before already and they never had any problem with it. I'm also confused about the lines before ENABLE_LAPTOP_MODE in acpi_support:
# Switch to laptop-mode on battery power - off by default as it causes odd
# hangs on some machines. (Note: This is reported to cause breakage in
# Debian - see deb bug #425800. Leaving enabled for Ubuntu for now
# since presumably it's still valid here.)

Revision history for this message
erythrocyte (erythrocyte) wrote :

i own a Dell Inspiron 1525 (officially listed as affected by this bug), and all the back and forth talk with regard to whether or not this bug has actually been fixed, is the number one reason why i haven't already installed ubuntu on my laptop... it would be great if the core team working on this bug along with Canonical and Dell, issues a loud and clear official statement to clear up the confusion.

Revision history for this message
Marius Vasilescu (vegancorr) wrote :

erythrocyte, I guess it still doesn't work in Intrepid, at least on my Dell Inspiron 1520 with a <a href="http://www.seagate.com/ww/v/index.jsp?vgnextoid=c7de03cf785c6110VgnVCM100000f5ee0a0aRCRD&locale=en-US">Seagate Momentus 5400.4</a> it didn't.

I did some testing, maybe this helps for debugging. I tried changing the bios settings for HDD Acoustic Mode to all three options ("bypass", "quiet", "performance"), but it didn't seem to make any difference, the cycle count kept increasing. I've tried to suspend my session, but after resuming the clicking was still present. After hdparm -B 254, the clicking stopped for good :)

Revision history for this message
Botond Szász (boteeka) wrote :

I agree with erythrocyte, a clear official statement need to be made on this subject. Such an important issue which may damage hardware, needs to be fixed quickly. More so if we take in consideration that Canonical wants Dell to put Ubuntu on its computers. How is Dell supposed to do such a thing knowing that Ubuntu will damage the hardware? This bug should be very high priority as it affects a whole range of notebooks. It should have been fixed for Hardy already, but even in Intrepid it is still there.

In Hardy I set ENABLE_LAPTOP_MODE=true /etc/default/acpi-support and CONTROL_HD_POWERMGMT=1 in /etc/laptop-mode/laptop-mode.conf and it seemed to work. After I upgraded to Intrepid and let these files be replaced by the ones coming from the upgrade, I still have this problem. So I tweaked the above files once again. I also run the hdparm -B 254 command which stopped the hard drive making clicks.

Revision history for this message
Mihail (ebay-mihai) wrote :

Sorry if I shouldn't post here - I have Mandriva 2008 - feel free to delete my post.
I want to add my 2 cents (did not see that mentioned when browsing through this discussion).
I manage to destroy (as in works now randomly, with a lot of noise and only for around 5 minutes) two external 500GB HDD's in only one night.
What I did - I tried to backup my internal HDD by copying it to the external HDD's. Since I selected separately which directories go on which HDD, I had 6 parallel copy commands from the internal HDD (3 parallel copy streams to each external HDD). I know it's stupid (and more slow), but I thought it would complete during the night.

In the morning both external disks were clicking like mad and the copies were stalled a little after the middle.
The internal HDD is still ok.
The extenal HDD's were a Samsung and a Hitachi HDT725050VLAT80, put in the same type of enclosure - (ACR-HD1098).
I thought first that the problem was due to trying to copy too much (and too many streams) at once. Now (after extensive googling for 2 weeks and one lucky search term today) it appears to me that it's the same bug mentioned here, but I don't understand why it would affect an external drive more than an internal one.

On the internal drive I have
193 Load_Cycle_Count 0x0032 195 195 000 Old_age Always - 16832
 3 Spin_Up_Time 0x0003 253 184 021 Pre-fail Always - 4141
 4 Start_Stop_Count 0x0032 100 100 000 Old_age Always - 295

Cannot get the counters from the external drives, but they do click like hell when they are working (once every 5 - seconds when I start them and they don't work, 5 or 6 time/minute at the lucky restart on which they work for more than 5 minutes):

Device: Hitachi HDT725050VLAT80 Version:
scsiModePageOffset: response length too short, resp_len=4 offset=4 bd_len=0
>> Terminate command early due to bad response to IEC mode page
A mandatory SMART command failed: exiting. To continue, add one or more '-T permissive' options
With -T verypermissive I get:
Error Counter logging not supported
Device does not support Self Test logging
Similar with the Samsung.

If I have the same bug, I did not see anyone mentioning that internal/external drives can be differently affected on the same system.
Hope that answers also Mark Baas question if it affects external drives - only external drives are affected on my system.
Any comment would be appreciated.

Revision history for this message
SirLancelot (lukaszgraczyk) wrote : Re: [Bug 59695] Re: High frequency of load/unload cycles on some hard disks may shorten lifetime

For me best solution in Hardy was:

Put:

http://launchpadlibrarian.net/12024037/90-hdparm.sh

In:

/home/[User_name]

And next:

sudo install 90-hdparm.sh /etc/acpi/resume.d/
sudo install 90-hdparm.sh /etc/acpi/start.d/
sudo install 90-hdparm.sh /etc/acpi/ac.d/
sudo install 90-hdparm.sh /etc/acpi/battery.d/

It was only way to hold load/unload hard drive cycles.

Any other methods discribed in:
https://wiki.ubuntu.com/PowerManagement

Failed.

But in Ubuntu 8.10 there are no good method for me to stop load/unload hard
drive cycles when I switch off AC cable and work my MSI VR610 Laptop on
Battery.

In the same configuration I had under Ubuntu 8.04 with no load cycles except
TurnOff... Now under Ubuntu 8.10 I have 6 load cycles per minute! It's too
much in my opinion.

Please describe good method to slow down cycles under Ubuntu 8.10!

2008/11/2 Botond Szász <email address hidden>

> I agree with erythrocyte, a clear official statement need to be made on
> this subject. Such an important issue which may damage hardware, needs
> to be fixed quickly. More so if we take in consideration that Canonical
> wants Dell to put Ubuntu on its computers. How is Dell supposed to do
> such a thing knowing that Ubuntu will damage the hardware? This bug
> should be very high priority as it affects a whole range of notebooks.
> It should have been fixed for Hardy already, but even in Intrepid it is
> still there.
>
> In Hardy I set ENABLE_LAPTOP_MODE=true /etc/default/acpi-support and
> CONTROL_HD_POWERMGMT=1 in /etc/laptop-mode/laptop-mode.conf and it
> seemed to work. After I upgraded to Intrepid and let these files be
> replaced by the ones coming from the upgrade, I still have this problem.
> So I tweaked the above files once again. I also run the hdparm -B 254
> command which stopped the hard drive making clicks.
>
> --
> High frequency of load/unload cycles on some hard disks may shorten
> lifetime
> https://bugs.launchpad.net/bugs/59695
> You received this bug notification because you are a direct subscriber
> of the bug.
>

--

Pozdrawiam Serdecznie.

Łukasz Graczyk

Revision history for this message
Botond Szász (boteeka) wrote :

@SirLancelot:

ENABLE_LAPTOP_MODE=true in /etc/default/acpi-support seems to work, my load cycle counter doesn't increase any more.

CONTROL_HD_POWERMGMT=1 in /etc/laptop-mode/laptop-mode.conf was already set in Intrepid, but you should take a look.

After setting these a restart is required to apply.

Hope it helps. It worked on my Inspiron 1525.

Revision history for this message
SirLancelot (lukaszgraczyk) wrote :

I have enabled all options that You described.

I have enabled all settings from:

https://wiki.ubuntu.com/PowerManagement

And:

#
# Idle timeout values. (hdparm -S)
# Default is 2 hours on AC (NOLM_HD_IDLE_TIMEOUT_SECONDS=7200) and 20
seconds
# for battery and for AC with laptop mode on.
#
LM_AC_HD_IDLE_TIMEOUT_SECONDS=7200
LM_BATT_HD_IDLE_TIMEOUT_SECONDS=300
NOLM_HD_IDLE_TIMEOUT_SECONDS=7200

#
# Power management for HD (hdparm -B values)
#
BATT_HD_POWERMGMT=200
LM_AC_HD_POWERMGMT=255
NOLM_AC_HD_POWERMGMT=255

And I put this script:

http://launchpadlibrarian.net/12024037/90-hdparm.sh

Into:

sudo install 90-hdparm.sh /etc/acpi/resume.d/
sudo install 90-hdparm.sh /etc/acpi/start.d/
sudo install 90-hdparm.sh /etc/acpi/ac.d/
sudo install 90-hdparm.sh /etc/acpi/battery.d/

And I still got 6 load/unload hard drive cycles per minute!

It's somethin different betwean 8.10 and 8.04! Under 8.04 I had only those
scripts and load/unload was only on PowerOff.

Help!

2008/11/2 Botond Szász <email address hidden>

> @SirLancelot:
>
> ENABLE_LAPTOP_MODE=true in /etc/default/acpi-support seems to work, my
> load cycle counter doesn't increase any more.
>
> CONTROL_HD_POWERMGMT=1 in /etc/laptop-mode/laptop-mode.conf was already
> set in Intrepid, but you should take a look.
>
> After setting these a restart is required to apply.
>
> Hope it helps. It worked on my Inspiron 1525.
>
> --
> High frequency of load/unload cycles on some hard disks may shorten
> lifetime
> https://bugs.launchpad.net/bugs/59695
> You received this bug notification because you are a direct subscriber
> of the bug.
>

--

Pozdrawiam Serdecznie.

Łukasz Graczyk

Revision history for this message
erythrocyte (erythrocyte) wrote :

@ Botond Szász

thanks for agreeing with me on this. i've opened up a brainstorm page to get this going and would like to see other users who see an official statement from Canonical/Dell as crucial, cast their votes of support. The idea is #15153 "Canonical And Dell Should Issue Official Statement About Hard-Drive Killer Bug" at http://brainstorm.ubuntu.com/idea/15153/ .

please do cast your votes today everyone!

..over and out

~
erythrocyte

Revision history for this message
Babyshamble (babyshamble) wrote :
Download full text (7.2 KiB)

Great idea erythrocyte

I want to reply to
AndrewLuecke<http://brainstorm.ubuntu.com/contributor/AndrewLuecke/>but
I don't have an user... I think that he's misleading the main issue
here. Yes, it's a "generic" bug, but Canonical: We need an official
statement on something that's very important because laptop market for SO is
also important... An also we need an fix for this, ok this is not "your"
problem, but it's happening on Ubuntu with laptops and it's critical to
assure market share in the future.

On Sun, Nov 2, 2008 at 2:51 PM, erythrocyte <email address hidden> wrote:

> @ Botond Szász
>
> thanks for agreeing with me on this. i've opened up a brainstorm page to
> get this going and would like to see other users who see an official
> statement from Canonical/Dell as crucial, cast their votes of support.
> The idea is #15153 "Canonical And Dell Should Issue Official Statement
> About Hard-Drive Killer Bug" at http://brainstorm.ubuntu.com/idea/15153/
> .
>
> please do cast your votes today everyone!
>
> ..over and out
>
> ~
> erythrocyte
>
> --
> High frequency of load/unload cycles on some hard disks may shorten
> lifetime
> https://bugs.launchpad.net/bugs/59695
> You received this bug notification because you are a direct subscriber
> of the bug.
>
> Status in The Dell Project: Confirmed
> Status in "acpi-support" source package in Ubuntu: Fix Released
> Status in "linux-meta" source package in Ubuntu: New
> Status in "pm-utils" source package in Ubuntu: New
> Status in acpi-support in Ubuntu Hardy: Triaged
> Status in linux-meta in Ubuntu Hardy: New
> Status in pm-utils in Ubuntu Hardy: New
> Status in "acpi-support" source package in Baltix: New
> Status in "acpi-support" source package in Debian: Fix Released
> Status in "pm-utils" source package in Fedora: Invalid
> Status in "laptop-mode-tools" source package in Mandriva: Confirmed
> Status in Suse Linux: Fix Released
>
> Bug description:
> This is not a support forum. Please do not use it as such (even though it
> has been used as such already).
>
> You can scan through the bug for links to the Ubuntu forums where many,
> many different questions have been asked, answered, and re-answered. The
> temporary workaround is just below.
>
> See https://wiki.ubuntu.com/PowerManagement for an overview about what is
> involved and for a remedy.
>
>
> Following is a summary of the issue:
> It is confirmed that some systems are seeing an unusually high number of
> load/unload cycles on their hard disks, as evidenced by smartctl.
>
> It was originally surmised that this was related to laptop-mode being
> enabled, but this especially affects systems where laptop-mode is disabled.
> In fact, aggressive APM is not a bad idea while a system is not on AC, as
> that system is much more likely to encounter a physical impact.
>
> This is due to disk APM settings that let the heads park or disk spin down
> after an idle period that is shorter than the regular disk access patterns
> of the OS.
>
> Then, the heads are only parked for a very short period of time and almost
> imediately loaded again. Making impact protection much ineffective and
> wearing out the drive.
>
> It can happen when the di...

Read more...

Revision history for this message
Endolith (endolith) wrote :

250 load cycles per hour in Intrepid. Doesn't seem like it's fixed to me.

Revision history for this message
foucault (michel-foucault) wrote :

1) I use my laptop almost the entire time on battery power. I bought one of this small, long-lasting Netbooks, which you can take everywhere and which you will not often use with power cable attached: an EeePC 1000H.
2) With Windows XP, i don't hear any clicks. There seem to be no load cycles while the laptop is on.
3) With default Intrepid, the head is parked every few seconds, far too much. I just can't see, how this should enhance battery power. I changed that to the save Windows XP behavior.
4) If Ubuntu could park the head and leave it there for some time, everything would be fine. Unfortunately, there is just too much disk access rendering the head parking thing entirely useless and destroying the hard disk.
5) If Ubuntu uses the hard disk that differently from Windows XP, and puts my hard disk at risk, I call it a bug. Intentionally implementing is even worse. I also found out, that while -B 191 parks the head roughly as often as -B 128, -B 192 doesn't park it at all.
6) Conclusion: fix this. As it seems, some hard disks work entirely different on this matter as others. The only way to fix this bug ist therefore the openSUSE way: Use a Blacklist that knows, how to handle specific disks and apart from that use safe values. Safe values as in: "Utilize the disk the same way Windows does, because that's what the manufacturer had in mind."

Revision history for this message
dimovnike (dimovnike) wrote :
Download full text (7.7 KiB)

just installed ubuntu intrepid - and again HDD clicks are going crazy :(
does anybody know if this is going to be fixed ?

On Mon, Nov 3, 2008 at 11:38 PM, foucault <email address hidden> wrote:

> 1) I use my laptop almost the entire time on battery power. I bought one of
> this small, long-lasting Netbooks, which you can take everywhere and which
> you will not often use with power cable attached: an EeePC 1000H.
> 2) With Windows XP, i don't hear any clicks. There seem to be no load
> cycles while the laptop is on.
> 3) With default Intrepid, the head is parked every few seconds, far too
> much. I just can't see, how this should enhance battery power. I changed
> that to the save Windows XP behavior.
> 4) If Ubuntu could park the head and leave it there for some time,
> everything would be fine. Unfortunately, there is just too much disk access
> rendering the head parking thing entirely useless and destroying the hard
> disk.
> 5) If Ubuntu uses the hard disk that differently from Windows XP, and puts
> my hard disk at risk, I call it a bug. Intentionally implementing is even
> worse. I also found out, that while -B 191 parks the head roughly as often
> as -B 128, -B 192 doesn't park it at all.
> 6) Conclusion: fix this. As it seems, some hard disks work entirely
> different on this matter as others. The only way to fix this bug ist
> therefore the openSUSE way: Use a Blacklist that knows, how to handle
> specific disks and apart from that use safe values. Safe values as in:
> "Utilize the disk the same way Windows does, because that's what the
> manufacturer had in mind."
>
> --
> High frequency of load/unload cycles on some hard disks may shorten
> lifetime
> https://bugs.launchpad.net/bugs/59695
> You received this bug notification because you are a direct subscriber
> of the bug.
>
> Status in The Dell Project: Confirmed
> Status in "acpi-support" source package in Ubuntu: Fix Released
> Status in "linux-meta" source package in Ubuntu: New
> Status in "pm-utils" source package in Ubuntu: New
> Status in acpi-support in Ubuntu Hardy: Triaged
> Status in linux-meta in Ubuntu Hardy: New
> Status in pm-utils in Ubuntu Hardy: New
> Status in "acpi-support" source package in Baltix: New
> Status in "acpi-support" source package in Debian: Fix Released
> Status in "pm-utils" source package in Fedora: Invalid
> Status in "laptop-mode-tools" source package in Mandriva: Confirmed
> Status in Suse Linux: Fix Released
>
> Bug description:
> This is not a support forum. Please do not use it as such (even though it
> has been used as such already).
>
> You can scan through the bug for links to the Ubuntu forums where many,
> many different questions have been asked, answered, and re-answered. The
> temporary workaround is just below.
>
> See https://wiki.ubuntu.com/PowerManagement for an overview about what is
> involved and for a remedy.
>
>
> Following is a summary of the issue:
> It is confirmed that some systems are seeing an unusually high number of
> load/unload cycles on their hard disks, as evidenced by smartctl.
>
> It was originally surmised that this was related to laptop-mode being
> enabled, but this especially affects systems where ...

Read more...

Revision history for this message
hvgotcodes (michael-e-harris) wrote :

I can confirm that after upgrading to intrepid my LCC is increasing at about 7 a minute. I have a Dell latitude E 6400 with 160GB/7200 RPM disk. I would say this bug still affects this laptop.

Revision history for this message
dauerflucher (dauerflucher) wrote :

Seagate Momentus 5400.3 ST980811AS (Dell Inspiron 1525) running Ubuntu 8.04.

Those harddisks are definitley affected by this issue. Round about 90000 cyles in 600 hours == 150 cycles / hour. I guess this was possibly kind of positively influenced by listen to music a lot keeping my harddisk busy.

I read through all the comments here - twice. Activated Laptop Mode as described in the Ubuntu Wiki and manually edited values in laptop-mode.conf. Except of some values I edited because they where changed by the activation of laptop mode (like readahead and idle_timeout) I checked various values for hdparm -B. Especially having a closer look on HDD temperature when AC powered.

-B 255 == 42°C (idle) - 48°C (moderate busy)
-B 254 == 41°C (idle) - 45°C (moderate busy)
-B 192 == 37°C (idle) - 40°C (moderate busy)

All three values have the same effect on load_cycly_count - no more clicking, no raising cycles.

This research I made was not very scientific and all in all I am absolutly not very experienced with such technical stuff. So I do not know how to achieve really significant results. But, I think I can dare saying that hdparm -B 192 is an appropriate value for Seagate Momentus 5400.3 ST980811AS - at least when AC powered.

I would like to see a real fix for this issue in Ubuntu - and all the other OSes - but I already can see the problems the devs will run into when trying to find values to address the broad mass of different harddisks all reacting differently on different values. Not mentioning the problems with laptop mode which most recently raised from the same problem. A real fix might come one day but until then the only thing that really helps is documentation.

Personally I would blame the devs only for missing forewarnings concerning this issue. It is know for a long time and I have to admit the simple user I am was pretty shocked when reading about this problem the first time some days ago.

Let's hope for the best.

Revision history for this message
Accesshater (youssef-email) wrote :

Installed intrepid on my Dell XPS M1530 and the hdd is still clicking =/
My only fix is that i use this command "sudo hdparm -B 255 /dev/sda" at startup. Really wth.

Revision history for this message
erythrocyte (erythrocyte) wrote :

Mark Shuttleworth responded to a question from somebody who obviously was aware of this issue and brainstorm idea http://brainstorm.ubuntu.com/idea/15153/ [Canonical And Dell Should Issue Official Statement About Hard-Drive Killer Bug] on the #ubuntu-classroom IRC channel on Freenode today. [jcastro aka Jorge Castro was moderator. sabdfl is aka Shuttleworth]. Pasting the transcript here for commentators:

--
15:39 jcastro QUESTION: Does Canonical ever make "Official Policy Announcements" on contentious issues? Two recent controversies were the hard drive wear issue and the issue with the Intel network cards being bricked. Are there official guidelines on what should be done when Ubuntu can possibly damage hardware?
15:40 sabdfl yes, we have a process for handling emergencies and screwups
15:40 sabdfl including making sure that we communicate clearly about what the situation is
15:40 sabdfl unfortunately we have that because there have been emergencies, and we have in the past occasionally screwed up
15:40 sabdfl but i think the policies are good
15:41 sabdfl i don't think such an issue is contentious - if we make a mistake, we need to sort it out, and keep people briefed
--

I think we should be pretty optimistic about hearing an official statement soon! wuhoo! :)

PS: couple of other hardware compatibility questions were relevant too such as:

--
16:25 jcastro QUESTION: The hardware database mentioned earlier seems limited to certifying whole machines. It seems like it would be more useful for most of us if we had a listing of individual hardware products that were known to work (or not work), particularly video and wireless cards...
16:25 jcastro QUESTION: .. Yet few wireless vendors would see the point in submitting their hardware for certification unless there were already a database to be added to. Is there a plan to get that sort of certification?
16:25 sabdfl i think jcastro pointed to the hardware database earlier
16:26 sabdfl we try to aggregate the information folks send us about their hardware
16:26 sabdfl it's difficult to do component-level certification
16:26 sabdfl because often, something breaks at the system level
16:26 sabdfl we do work with component manufacturers, though, if there is a machine that needs to be enabled
--

I had missed the earlier questions, so asked this crucial question just in case:

--
6:55 jcastro QUESTION: how robust is the laptop certification process between Canonical and its partners? should customers expect 0% system breakage (in terms of hardware or software)?
16:56 sabdfl they should expect it, and we strive to deliver it
16:56 sabdfl see above for how we handle emergencies and screwups :-)
--

cheers everybody! #ubuntu-classroom is a great place to hang out! :D

Revision history for this message
angel chen (angelchen1111) wrote :

Just change the line “if [ -e /usr/sbin/laptop_mode ] ; then” in 90-hdparm.sh to “if [ -e /var/run/laptop-mode-tools/enabled ] ; then” because that script is checking if /usr/sbin/laptop_mode exists rather than if laptop mode tools is enabled. Once laptop-mode-tools is installed, the file /usr/sbin/laptop_mode is always there whether it is enabled or not.

Revision history for this message
bojo42 (bojo42) wrote :

@angel chen: i can confirm that on intrepid with all updates applied, the four 90-hdparm.sh scripts never come to hdparm, cause $DO_HDPARM is always set to "n". just like you said, it really needs to be changed otherwise the scripts won't fix load cycling on ac.

but as your change will finally result in $DO_HDPARM=y on my side, it also does the same when running the script from battery.d. and AFAIK laptop mode should be enabled on battery and therefore $DO_HDPARM should be "n". the same should be the case with the script in start.d, when you booting your laptop on battery. am i right?

Revision history for this message
bojo42 (bojo42) wrote :

@angel chen: i just checked for laptop mode on battery with "cat /proc/sys/vm/laptop_mode" and so it seem as laptop mode is also disabled on intrepid. so your fix to the script should be okay in all situations.

but is just thought what's better to check if laptop mode is on:

"if [ -e /var/run/laptop-mode-tools/enabled ] ; then"
or something like
"if [ $(cat /proc/sys/vm/laptop_mode) != 1 ]; then"

who knows whats more reliable?

Revision history for this message
bojo42 (bojo42) wrote :

oops i mixed it up, it should be:
"if [ $(cat /proc/sys/vm/laptop_mode) != 0 ]; then"

Revision history for this message
Botond Szász (boteeka) wrote :

The laptop-mode-tools webpage says:

"
3. Is Laptop Mode Enabled?
How do I check if laptop mode is enabled?

Execute cat /proc/sys/vm/laptop_mode. If it contains a nonzero value, then laptop mode is enabled, if it says 0, then it isn't.
What's /var/run/laptop-mode-enabled got to do with things?

Well, this file is created and destroyed by the laptop-mode init script to enable/disable laptop mode activity. If this file is not present, then laptop mode tools will not do a thing except disable itself, even when you unplug your computer from the mains.
And what about /etc/default/laptop-mode?

That's only supported for backward compatibility with the old Ubuntu laptop-mode package. It contains a setting using which you can enable or disable laptop mode entirely.
"
[http://samwel.tk/laptop_mode/faq]

But you probably have already seen it, I guess.

Revision history for this message
angel chen (angelchen1111) wrote :

For me for some reason /proc/sys/vm/laptop_mode is always zero even if laptop mode tools is enabled.

Revision history for this message
angel chen (angelchen1111) wrote :

bojo42 says:
""
@angel chen: i can confirm that on intrepid with all updates applied, the four 90-hdparm.sh scripts never come to hdparm, cause $DO_HDPARM is always set to "n". just like you said, it really needs to be changed otherwise the scripts won't fix load cycling on ac.

but as your change will finally result in $DO_HDPARM=y on my side, it also does the same when running the script from battery.d. and AFAIK laptop mode should be enabled on battery and therefore $DO_HDPARM should be "n". the same should be the case with the script in start.d, when you booting your laptop on battery. am i right?
""
Yes, we do need to update all files. Also how come the file /etc/init.d/laptop-mode says

# FIXME: this shouldn't be configured there
if [ -f /etc/default/acpi-support ]; then
. /etc/default/acpi-support;
fi

if [ x$ENABLE_LAPTOP_MODE = xfalse ]; then
exit 0;
fi

which causes the laptop mode tools script won't be able to execute at all if ENABLE_LAPTOP_MODE is set to false.

Revision history for this message
Grizzly (sven-witterstein) wrote :

Just to confirm, that some turion64 notebook on a fresh intrepid install with a replacement SAMSUNG HM080GC drive that is so silent that I can't hear its clicks (or the fan on that b***ch is too loud) even with the commit=120 on mounting the ext3 root system ticks++ load cycles every 5secs (probably I need to set the "Kernel commit interval" or my xfs-systems for /home and backup make the problems. When unpluggung AC, no /proc/sys/vm/laptop-mode gets a nonzero value, however the screen darkens.

As I have no "hdparm" to tick in "System-Services" I just use /etc/rc.config with the old familar hdpamr -B 254...)
The hdd is COOLER then

BTW: on hardy I got it fixed with reducing commit times etc. ppp. Thought is was fixed on intrepid, now I see it's worse then used to be...

Is this also on SATAs or only on last-generation IDEs?

Revision history for this message
bojo42 (bojo42) wrote :

@angel chen: good question. i'm somewhat confused by that, but when laptop mode is disabled in general in /etc/default/acpi-support then logically it shouldn't be enabled by default on battery either. but you could you tell me how you started laptop mode when "cat /proc/sys/vm/laptop_mode" still gives you a zero.

@all: who knows for sure if laptop mode is enabled on battery in intrepid?

who knows how to reliable check if laptop mode is enabled, for fixing the included scripts in intrepid?

Revision history for this message
Guillermo Pérez (bisho) wrote :

Last attachment from der64hva3 is malware!

Revision history for this message
Chow Loong Jin (hyperair) wrote :

On Mon, 2008-11-10 at 15:38 +0000, Guillermo Pérez wrote:
> Last attachment from der64hva3 is malware!
>
That should be pretty obvious. You're free to click it anyway, it's
harmless if you use Ubuntu (and you should be ;)

Anyway I've informed the guys at #launchpad so it should be removed
pretty soon I guess.
--
Chow Loong Jin

Revision history for this message
Guillermo Pérez (bisho) wrote :

> That should be pretty obvious. You're free to click it anyway, it's
> harmless if you use Ubuntu (and you should be ;)

For sure! But perhaps the .exe may run well under wine :)))

Revision history for this message
Bart Samwel (bart-samwel) wrote : Re: [Bug 59695] Re: High frequency of load/unload cycles on some hard disks may shorten lifetime

bojo42 wrote:
> @angel chen: good question. i'm somewhat confused by that, but when
> laptop mode is disabled in general in /etc/default/acpi-support then
> logically it shouldn't be enabled by default on battery either. but you
> could you tell me how you started laptop mode when "cat
> /proc/sys/vm/laptop_mode" still gives you a zero.
>
> @all: who knows for sure if laptop mode is enabled on battery in
> intrepid?
>
> who knows how to reliable check if laptop mode is enabled, for fixing
> the included scripts in intrepid?

Checking for /proc/sys/vm/laptop_mode is not the way to go. This is to
check if the _kernel feature_ called "laptop mode" is enabled. What you
need to check for is whether the relevant functionality of the _package_
laptop-mode-tools is enabled, a very different thing (yes, the name
"laptop-mode-tools" is a confusing name -- blame history!). Because if
it is, then laptop-mode-tools will handle this stuff regardless of
battery, non-battery, and the state of the kernel feature that is
represented by /proc/sys/vm/laptop_mode. (The /proc/sys/vm/laptop_mode
feature is also controlled by laptop-mode-tools, but this is independent
of the hdparm features and should absolutely be ignored!) How to check
if (a) the _package_ laptop-mode-tools is enabled AND (b) its feature
controlling hdparm is enabled? Well:

(a): by checking /etc/default/acpi-support for ENABLE_LAPTOP_MODE=true
(b): by executing /etc/laptop-mode/laptop-mode.conf and testing whether
CONTROL_HD_POWERMGMT=1

The current 90-hdparm.sh already does (b). One should simply add (a).
One could replace this:

if [ -e /usr/sbin/laptop_mode ] ; then
  LMT_CONTROL_HD_POWERMGMT=$(. /etc/laptop-mode/laptop-mode.conf && echo
"$CONTROL_HD_POWERMGMT")
  if [ "$LMT_CONTROL_HD_POWERMGMT" != 0 ] ; then
    # Laptop mode controls hdparm -B settings, we don't.
    DO_HDPARM=n
  fi
fi

by:

if [ -e /usr/sbin/laptop_mode ] ; then
  LMT_CONTROL_HD_POWERMGMT=$(. /etc/laptop-mode/laptop-mode.conf && echo
"$CONTROL_HD_POWERMGMT")
  ACPI_SUPPORT_ENABLE_LAPTOP_MODE=$(. /etc/default/acpi-support && echo
"$ENABLE_LAPTOP_MODE")
  if [ "$LMT_CONTROL_HD_POWERMGMT" != 0 &&
"$ACPI_SUPPORT_ENABLE_LAPTOP_MODE" = "true" ] ; then
    # Laptop mode controls hdparm -B settings, we don't.
    DO_HDPARM=n
  fi
fi

and that should do the trick.

Cheers,
Bart

Revision history for this message
bojo42 (bojo42) wrote :

@Bart: thanx for your help. this seems a good solution and i can confirm it works on my laptop.

so if any ubuntu dev should read this and feels bored ;) please provide an update of acpi-support with Bart's corrections to those scripts. so we would have this issue solved under intrepid by default and without enabling laptop mode. :)

Revision history for this message
Tor Arne Pedersen (tor-pedersen) wrote :

Hello!

I see that status for Ubuntu and this bug is "Fix released", but I see that users still experience this bug in Intrepid. Killing users hard drives is serious stuff, and this should be refixed and rereleased, right? This seems to be the issue for Thinkpad T61 as well. Users are going away from Ubuntu over this issue. Should status be changed until final fix is released?

--
Tor Arne Pedersen

Revision history for this message
ramas (slocascio) wrote : Re: [Bug 59695] Re: High frequency of load/unload cycles on some hard disks may shorten lifetime

Btw I experience clicks also under Windows Vista...I have a Dell Inspiron 6400

--
Saluti,
Sergio

Revision history for this message
angel chen (angelchen1111) wrote :

quote: Btw I experience clicks also under Windows Vista...I have a Dell Inspiron 6400

Samething with me for my Vostro 1400 and no workaround.

Revision history for this message
hasan (hassanidin) wrote :

I purchased a DELL XPS M1530 with linux preloaded specifically in order to avoid having to deal with this bug (which killed my last laptops hard-drive), but to my shock, once I installed 8.10 on the XPS, the load cycle count was still increasing at an alarming rate (+1 every 10secs).

I am really disappointed that more than one year after its discovery this bug continues to plague Ubuntu. I do not know if it is Dell or Ubuntu that is at fault here, but the current situation is clearly unacceptable. We need our hard disks to last.

Revision history for this message
Endolith (endolith) wrote :

"I do not know if it is Dell or Ubuntu that is at fault here"

Doesn't matter who's at fault. What matters is Ubuntu implementing a workaround so they aren't destroying their users' hardware. I don't understand why this says "Fix Released" on it when it's clearly not fixed.

Nanley Chery (nanoman)
Changed in acpi-support:
status: Fix Released → In Progress
Revision history for this message
Tom Jaeger (thjaeger) wrote :

I've added an acpi-support package containing Bart's fix to my PPA:

http://ppa.launchpad.net/thjaeger/ubuntu/pool/main/a/acpi-support/

Revision history for this message
xenesis (wagner-sim88) wrote :

As far as I can tell, the bug is still not fixed.
However after my own experience it is very difficult to fix this bug, as some hardware manufactors seem to have screwed up their power management.

I myself have a Dell Inspiron 1720, whose Hard Disk had problems with an increasing Load Cycle Count under Intrepid. My fix was to enable laptop-mode-tools, setting the hdparm -B value to 255 (254 was useless) and to enable via BIOS the Quiet mode for my HD. (Was somewhere under power management).

To me it seems that the whole problems seems to come from some specific technologies like Seagates QuietStep. The idea is, not to stop to HD, but to spin it down first and then when its longer inactive, it is really stopped. However without any specific setting, Ubuntu seems to use the vendor settings of HD, but instead of first spinning down, the HD is stopped. Thats wrong, because the vendors intention was to first spin it down a bit and that causes the increasing load cycle count.

The only possible way to fix this is to activate somehow the vendor specific technology. For my Seagate HD, the above described way worked. However, as this is vendor specific technology, this fix won't work for all.

That seems for me to be the reason, why we need sometimes 254, sometimes 255, and sometimes some odd BIOS setting.

Revision history for this message
Alvaro Kuolas (kuolas) wrote :

I've read 620 post and nobody looked at this:

https://bugs.launchpad.net/ubuntu/+source/acpi-support/+bug/124119

The problem is in acpi-support and a load of other scripts/programs (laptop-mode, GnomePowerManager, kde-guidance-powermanage and others) that interfere with each others.

This is an anarchy.

We should have a single way to manage this.

So, pm-utils would be it?

Revision history for this message
DGMcCloud (duncan-doyle) wrote :

In my opinion, the problem is not in those scripts, nor is it a Dell problem. The problem is the crappy power management in laptop HDDs. I own a Dell D820 with a Hitachi HDD by the way.

I recently had contact with Hitachi technical support on this issue. They advised me to put my HDD APM to setting "Active Idle" (setting 192) using their own Hitachi tool. The Dell bios on my system doesn't even touch the drives APM settings, it is controlled by the HDD firmware settings itself (and can be changed). Setting APM to 192 using the Hitachi Tool is basically the same as executing the 'hdparm -B 192 /de/sda' in Ubuntu, the only difference is that this is now the drives default (which used to be 128).

In my opinion (I have no scientific data to back this up, its just something I observed), the APM, and especially the disk head parking time (the clicking noise is the disk head parking) is set to a Windows timing. What I mean with this is that most of the time (unless you're doing nothing for a long time) Windows is accessing the disk every 4 or 5 seconds, which is too fast for the disk heads to park. However, Linux is much more disk efficient, accessing the disk at a slightly higher interval (say 8 seconds). What happens is that the Linux disk access timing has an idle time which is high enough for the heads to park, and just after they've parked, the disk is accessed again. In my opinion, this is what is causing the LoadCycleCount to increase so rapidly on Ubuntu (and other Linux distro's for that matter).

What would be a good solution is to have a disk head parking time (the idle time needed for the disk heads to park) which is configurable. However, at least on my Hitachi drive, this can't be done. Setting APM to 191 uses the same timing as 128, and 192 switches head parking off completely. There is absolutely no way to control the timing. Another option would be to configure Linux in such a way that it accesses the disk at a much higher rate OR a much lower rate. Either option would be sufficient to solve the problem. The only difference is that with a higher disk access rate, the heads will not park that often (but will park when you're doing nothing at all).

Revision history for this message
Ryan Waldroop (ryan.waldroop) wrote : Re: [Bug 59695] Re: High frequency of load/unload cycles on some hard disks may shorten lifetime

On Mon, 2008-11-24 at 17:31 +0000, DGMcCloud wrote:
> What would be a good solution is to have a disk head parking time (the
> idle time needed for the disk heads to park) which is configurable.
> However, at least on my Hitachi drive, this can't be done. Setting APM
> to 191 uses the same timing as 128, and 192 switches head parking off
> completely. There is absolutely no way to control the timing. Another
> option would be to configure Linux in such a way that it accesses the
> disk at a much higher rate OR a much lower rate. Either option would be
> sufficient to solve the problem. The only difference is that with a
> higher disk access rate, the heads will not park that often (but will
> park when you're doing nothing at all).

I would *love* to see something like this. Personally, I'm not too
worried about losing the head protection "feature"...I don't really see
how having the head parked for 1 second out of 10 will really help that
much. I, too, would like to park the heads only after it being idle for
say 10 seconds.

Revision history for this message
Alvaro Kuolas (kuolas) wrote :

I thought that this could be easily fixable with "hdparm -B 128" for battery and "hdparm -B 254" on AC. Ok, we need to work around some HDD quirks but the rest is straight forward. The hard drive itself is no so important, this is true if the drive conforms with hdparm instructions. In my case I've tested WDIDLE3.EXE on FreeDOS and disable the "idle3", but it behaves the same on Ubuntu thanks to acpi-support. laptop-mode is conflicting with acpi-support. I don't know why GnomePowerManager do it's own stuff.

We need a centralized Power Management support.

SuSE have this, pm-utils and a black list.

I think that is a good solution, and would be now. If we wait to the ultimate solution, maybe by then it will be too late.

Revision history for this message
Tore Anderson (toreanderson) wrote : Re: [Bug 59695] Re: High frequency of load/unload cycles on some hard disks may shorten lifetime

* Alvaro Kuolas

> We need a centralized Power Management support.

Yep. Status quo is chaotic.

Maybe this could be used? Never looked closely at it, though.

http://lesswatts.org/projects/power-policy/

--
Tore Anderson

Revision history for this message
Tom Jaeger (thjaeger) wrote :

Please consider a SRU. Packages are in my ppa: http://ppa.launchpad.net/thjaeger/ubuntu/pool/main/a/acpi-support/

acpi-support (0.115) intrepid; urgency=low

  * acpi_fakekey: send keys through uinput (requires new acpi_fakekeyd daemon)
    (LP: #217504)

  * 90-hdparm.sh: correctly test whether laptop-mode-tools is controlling
    hdparm settings (LP: #59695)
    https://bugs.launchpad.net/ubuntu/+source/acpi-support/+bug/59695/comments/612

 -- Thomas Jaeger <email address hidden> Sat, 29 Nov 2008 11:38:17 -0500

Revision history for this message
Tom Jaeger (thjaeger) wrote :

Tiny whitespace update.

Revision history for this message
bojo42 (bojo42) wrote :

@Tom: Many thanx for providing the deb & debdiff.

But one last issue need to be fixed manually if you want these fixes to function at wakeup from suspend. So we should run

sudo ln -s /etc/acpi/resume.d/90-hdparm.sh /etc/pm/sleep.d/

after installing the package from PPA. This probably can't be fixed in the acpi package, so an update to the pm-utils would be also necessary, either containing a link or a copy of the script.

Revision history for this message
Endolith (endolith) wrote :

I don't understand any of this, and my drive is at 1,348,046 load cycles and climbing.

Is there going to be a fix released any time in the near future?

If not, is there a simple guide on how to work around it? I've used "sudo hdparm -B 128 /dev/sda" and it seems to work, but it doesn't "stick" and I have to keep entering the command.

Revision history for this message
Vincenzo Ciancia (vincenzo-ml) wrote :

I still have this problem on up-to-date intrepid, and it is absolutely not clear how many files you have to edit by hand, and how many things you have to watch for when upgrading the system to avoid your changes being reset.

For now, I created a script that I added to init.d. Every two minutes, the script logs sensors infomation and load cycles, and sets hdparm -B again. It works well.

I commented out the setting of hdparm (so that the script just logs) and got a log in intrepid (up to date, a couple of days ago) that clearly shows load cycles going up and up. I attach my log and the script that I use for others to use.

Revision history for this message
Vincenzo Ciancia (vincenzo-ml) wrote :

Please improve my scripts at your will and publish it. Also, the script may be the source of complex calculations of the hdparm -B value, that depend e.g. on temperature and battery status.

Revision history for this message
Vincenzo Ciancia (vincenzo-ml) wrote :
Revision history for this message
bojo42 (bojo42) wrote :

HOWTO fix this problem on Ubuntu 8.10:

An up-to-date Ubuntu 8.10 (in it's default state) includes fixes for this problem in it's "acpi-support" package. But they do not work because there's a small failure in the scripts.

Therefore you can correct these scripts manually (just like written in https://bugs.launchpad.net/ubuntu/+source/acpi-support/+bug/59695/comments/612 ) or you simply install the updated package including these fixes form Tom's PPA http://ppa.launchpad.net/thjaeger/ubuntu/pool/main/a/acpi-support/ .

And when you want those stuff also to function at the wakeup from suspend, you should just run
sudo ln -s /etc/acpi/resume.d/90-hdparm.sh /etc/pm/sleep.d/
in a terminal next to you.

It is just as easy as this. After done that you only need to plug off and in your AC to get the fixes working. BTW they are designed to work exclusively at AC, as they would otherwise deactivate the shock protection of your laptop's harddrive when running on battery.

Revision history for this message
Endolith (endolith) wrote :

> BTW they are designed to work
> exclusively at AC, as they would otherwise deactivate the shock
> protection of your laptop's harddrive when running on battery.

Worrying about "protecting" the laptop from dropping seems dubious.

1. I am just as likely to drop the laptop in AC power as in battery power
2. If I'm on battery power, there's no guarantee that when I drop it the head will happen to be parked.
3. Is it true that a hard drive's built-in drop protection is disabled when told not to park the heads? If it has an actual "drop protection" feature, it seems unlikely that it would ever be disabled.

Revision history for this message
bojo42 (bojo42) wrote :

@Endolith: The setting for battery mode is a compromise between powersaving&shockprotection vs. load cycling. When you don't go with that or use battery very often, just change the hdparm value in the condition for battery, it's the line after "if [ $STATE = "BATTERY" ] ; then" in the scripts.

Revision history for this message
Endolith (endolith) wrote :

> The setting for battery mode is a compromise between powersaving&shockprotection vs. load cycling.

I sure hope not.

All I'm saying is that the "shock protection" effect seems to be largely imaginary. Power saving is good, sure, but I really hope this whole hard drive-destroying problem wasn't created in a misguided attempt to protect drives when they are dropped. Dropping a laptop is not exactly normal use, and the chances that this would actually protect your drive seem pretty slim.

If you drop it on AC, it's going to break. If you drop it on batteries while the head happens to not be parked, it's going to break. No matter what hdparm is set to, if you drop it hard enough, it's going to break.

Revision history for this message
Endolith (endolith) wrote :

> or you simply install the updated package including these fixes form
> Tom's PPA http://ppa.launchpad.net/thjaeger/ubuntu/pool/main/a/acpi-support/ .

Thank you! Confirmed that this works on a Dell Inspiron 8600 with a Hitachi HTS721010G9AT00. There are load cycles on battery power but not on AC.

Revision history for this message
Isaac Dupree (idupree) wrote :

Intrepid x86_64 MacBook2,1. (a page related to this hardware: https://help.ubuntu.com/community/MacBook2-1/Hardy )

bad: Wait 10 minutes (working or not, but system running), and Load_Cycle_Count increases by 5 to 10. That's 30-60 LCC an hour, which is too much.

`hdparm -B 254 /dev/sda` works as long as it lasts, which is until suspend or reboot. It seems to prevent Load_Cycle_Count increasing (except by 1 when suspending to ram or rebooting of course). My particular hard-drive specs seem to say that hdparm value will make it wait 15 minutes before parking the head, so it's possible it would park after 15 minutes of actual disk inactivity, which would be a good thing (I wasn't patient enough to check).

Enabling laptop-mode (in /etc/default/acpi-support -- I know it worked because then, on battery, /proc/sys/vm/laptop_mode would contain 2 rather than 0) didn't solve Load_Cycle_Count increasing, neither when on battery nor when on AC, and even though /etc/laptop-mode/laptop-mode.conf settings are mostly good in their default e.g. CONTROL_HD_POWERMGMT=1, LM_AC_HD_POWERMGMT=254, NOLM_AC_HD_POWERMGMT=254, LM_AC_MAX_LOST_WORK_SECONDS=360... though it's possible that both AC and battery are slipping through the cracks in various ways (maybe battery, uses HD_POWERMGMT=1, and AC, not on LM and doesn't save disk-writes over time). (I also noticed that, while writes can be delayed given enough RAM, reading data from the disk that's not already cached -- e.g. starting up a new application -- cannot be, so we're just relying on that not being needed most of the time a computer's running in laptop-mode.)

I put this into /etc/pm/sleep.d/99-save-hd.sh (with chmod +x) (note bug #244839) :
{{{
#!/bin/sh
hdparm -B 254 /dev/sda
}}}
It runs, once on each suspend and once on each resume, which works for me (Load_Cycle_Count measured not increasing). I'm not sure if that script, or indeed anything, runs on system start, though -- but I personally mostly suspend/resume and rarely shut down, so this works good enough for me.

Revision history for this message
sv3t (tassev) wrote :

I recently started using the "Power Management gui" wattospm:
http://ubuntuforums.org/showpost.php?p=6362540&postcount=103
http://ubuntuforums.org/showthread.php?t=988309
It solved all my problems.

It comes with a deamon which loads on startup. So, the values for hdparm etc it loads are not lost after reboot for example. I changed the "on battery" and "on AC" hdparm parameters as suggested in this thread, and now I have no more problems with increasing load/unload cycles. Moreover, after playing a bit with the rest of the settings, now the consumption of my lenovo t60 on battery is only 13.5W !!! -- as much as it consumed running windows that came with it (that was before I switched to ubuntu. After I did that the consumption never fell below ~18Watts).

I really hope people help this guy and start shipping this nice piece of code with ubuntu!

Revision history for this message
Paganini (nebanks) wrote :

I have a Thinkpad X40 with a Hitachi hard disk. It is a C4Kxx series disk, which is not supported by Hitachi's "Feature Tool," so I'm unable to change the default APM settings in the disk's firmware.

I've been following this bug and its related threads closely and implemented the most recent fixes. The fixes *do* work, in the sense that I can query the drive using 'hdparm -I' and it reports that power management has been disabled, or set to 254 or 1 or whatever value the scripts mandate.

And yet, the drive just sits there clicking away 1 to 3 times a minute, and the load cycle count keeps going up. I just now (in the last 5 minutes) listened to it click 3 times, got a terminal and ran 'hdparm -I' which says "Advanced power management level: disabled" and listened to it resume clicking, just like clockwork. It really has me stumped.

Revision history for this message
Paganini (nebanks) wrote :

One thing I have *NOT* seen discussed on any of the forums is the "lesser of two evils" question:

Windows seemingly does not have this problem (or at least, doesn't have it often) because it never lets the disk alone long enough for the heads to unload. Its pretty easy to duplicate that behavior in linux - a cron job that touches some file every 5, 10, 15, or whatever seconds.

So the question is, what is really more damaging to a drive - a excessive number of load cycles, or continuous operation?

Since I haven't heard a lot of people complaining that Windows wears out their disks by never letting them park, I assume that the "Windows solution" is at least acceptable. I wonder if anyone has any concrete data about hard drives being killed by too many load cycles.

Revision history for this message
Hanno Stock (hefe_bia) (hanno-stock) wrote :

Does this actually have to do with Ubuntu accessing the disk for *read/write* or may this be related to some other kind of polling? (Temperature, etc.)

I ran iotop on my laptop in AC mode with hdparm -B 199. While iotop showed no disk activity at all, frequent load/unload cycles occured.

I also noticed that running smartctl -a when the heads are parked the heads are unparked immediately. Can I somehow monitor hard disk activity besides read/write activity? (For example SMART polling, etc.)

Revision history for this message
Alexey Borzenkov (snaury) wrote :

Hanno, I don't really remember, but I think back when I was investigating problems with my Samsung drive I found that iotop didn't show all the interesting values and was patching it to be more precise. Also, please be aware, that querying smart will always unpark drive heads, because smart values (I think) have to be read from special sectors on your drive. The same goes for ANY hard drive temperature monitoring (because they ALL have to query smart to get drive temperature), so remove hddtemp if you have it installed.

If you want your drive to stay parked longer try enabling laptop-mode (look at /etc/laptop-mode/laptop-mode.conf for details and don't forget to set ENABLE_LAPTOP_MODE=true in /etc/default/acpi-support). What you must be interested in is *_MAX_LOST_WORK_SECONDS, but it will work on AC only when you have ENABLE_LAPTOP_MODE_ON_AC=1. You might, just like me, find it a lot better for your drive to stay spinned down than to have it constantly working with disabled APM.

Revision history for this message
Sambit Bikas Pal (sambitbikaspal) wrote :

I had made a post here -
http://www.botcyb.org/2008/12/linux-hard-disk-issue-excessive.html
on the issue of excessive load cycle count. You may have a look at it
if you wish.

On 29/12/2008, Alexey Borzenkov <email address hidden> wrote:
> Hanno, I don't really remember, but I think back when I was
> investigating problems with my Samsung drive I found that iotop didn't
> show all the interesting values and was patching it to be more precise.
> Also, please be aware, that querying smart will always unpark drive
> heads, because smart values (I think) have to be read from special
> sectors on your drive. The same goes for ANY hard drive temperature
> monitoring (because they ALL have to query smart to get drive
> temperature), so remove hddtemp if you have it installed.
>
> If you want your drive to stay parked longer try enabling laptop-mode
> (look at /etc/laptop-mode/laptop-mode.conf for details and don't forget
> to set ENABLE_LAPTOP_MODE=true in /etc/default/acpi-support). What you
> must be interested in is *_MAX_LOST_WORK_SECONDS, but it will work on AC
> only when you have ENABLE_LAPTOP_MODE_ON_AC=1. You might, just like me,
> find it a lot better for your drive to stay spinned down than to have it
> constantly working with disabled APM.
>
> --
> High frequency of load/unload cycles on some hard disks may shorten lifetime
> https://bugs.launchpad.net/bugs/59695
> You received this bug notification because you are a direct subscriber
> of the bug.
>

--
Sambit Bikas Pal
MS 3rd Year
Indian Institute Of Science Education & Research Kolkata,
HC 7, Sector-III Salt Lake, Kolkata-700106
Web: http://www.botcyb.org
OpenPGP Key: http://keyserver.ubuntu.com:11371/pks/lookup?op=get&search=0x8E57F8B897D372B3

NB: Kindly send mails as "text/plain".

Revision history for this message
Bart Samwel (bart-samwel) wrote : Re: [Bug 59695] Re: High frequency of load/unload cycles on some hard disks may shorten lifetime

Hi Alexey,

Alexey Borzenkov wrote:
> Hanno, I don't really remember, but I think back when I was
> investigating problems with my Samsung drive I found that iotop didn't
> show all the interesting values and was patching it to be more precise.
> Also, please be aware, that querying smart will always unpark drive
> heads, because smart values (I think) have to be read from special
> sectors on your drive. The same goes for ANY hard drive temperature
> monitoring (because they ALL have to query smart to get drive
> temperature), so remove hddtemp if you have it installed.

My drive parks just fine with hddtemp. And smart doesn't necessarily
require storage on a special sector -- the drive could also be using
some sort of nvram. So your mileage may vary, it may all depend on the
drive.

Cheers,
Bart

Revision history for this message
Endolith (endolith) wrote :

> I had made a post here -
> http://www.botcyb.org/2008/12/linux-hard-disk-issue-excessive.html
> on the issue of excessive load cycle count. You may have a look at it
> if you wish.

So it's Bug 294190 that's primarily responsible for the hard drive spinning back up every few seconds? How annoying.

Revision history for this message
hanciong (be-happy-milenium) wrote :

helo. after I use smartctl command, there is no min/max temperature. here is the result:

hanciong@hanciong-laptop:~$ sudo smartctl -a /dev/sda | egrep '(Load_Cycle_Count|Temperature)'
193 Load_Cycle_Count 0x0032 189 189 000 Old_age Always - 33392
194 Temperature_Celsius 0x0022 097 077 000 Old_age Always - 46

look at the bottom line, there is only 46 (my laptop temperature now). there is no min/max temperature information. do you know why? my laptop is acer 4920. any suggestion is greatly appreciated.

Revision history for this message
Chow Loong Jin (hyperair) wrote : Re: [Bug 59695] Re: High frequency of load/unload cycles on some hard disks may shorten lifetime

On Sat, 2009-01-03 at 15:16 +0000, hanciong wrote:
> helo. after I use smartctl command, there is no min/max temperature.
> here is the result:
>
> hanciong@hanciong-laptop:~$ sudo smartctl -a /dev/sda | egrep '(Load_Cycle_Count|Temperature)'
> 193 Load_Cycle_Count 0x0032 189 189 000 Old_age Always - 33392
> 194 Temperature_Celsius 0x0022 097 077 000 Old_age Always - 46
>
> look at the bottom line, there is only 46 (my laptop temperature now).
> there is no min/max temperature information. do you know why? my laptop
> is acer 4920. any suggestion is greatly appreciated.
>
smartctl isn't supposed to be used for getting the hard disk temperature
unless I'm mistaken. Use hddtemp instead.
--
Chow Loong Jin

Revision history for this message
hanciong (be-happy-milenium) wrote :

Chow Loong Jin, what is exactly the command for hddtemp? thx a lot

smartctl isn't supposed to be used for getting the hard disk temperature
unless I'm mistaken. Use hddtemp instead.
--

Revision history for this message
Noel J. Bergman (noeljb) wrote :

> what [is] the command for hddtempF

First:

  sudo apt-get install hddtemp

then run hddtemp.

Revision history for this message
Steve Langasek (vorlon) wrote :

The intrepid changes to acpi-support and laptop-mode-tools look self-evidently correct and would be acceptable for SRU, but a check on an intrepid system shows that Load_Cycle_Count is still incrementing until I call hdparm -B 254 by hand. So something is still missing, at least for intrepid...

Revision history for this message
Steve Langasek (vorlon) wrote :

I've had a look at the acpi-support diff, and the reason this fix isn't taking effect is this code:

DO_HDPARM=y
if [ -e /usr/sbin/laptop_mode ] ; then
  LMT_CONTROL_HD_POWERMGMT=$(. /etc/laptop-mode/laptop-mode.conf && echo "$CONTROL_HD_POWERMGMT")
  if [ "$LMT_CONTROL_HD_POWERMGMT" != 0 ] ; then
    # Laptop mode controls hdparm -B settings, we don't.
    DO_HDPARM=n
  fi
fi

This checks whether laptop-mode is configured to use hdparm, but fails to check whether laptop-mode is *enabled* on the system, which it isn't by default.

Will integrate an additional check for /var/run/laptop-mode-tools/enabled, which is what laptop-mode itself uses at runtime.

Steve Langasek (vorlon)
Changed in acpi-support:
status: New → Triaged
Revision history for this message
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package acpi-support - 0.115

---------------
acpi-support (0.115) jaunty; urgency=low

  * {ac,battery,resume,start}.d/90-hdparm.sh: don't just check whether
    laptop-mode is configured to control the drives, also check whether
    laptop-mode itself is *enabled*. Finally closes LP: #59695.

 -- Steve Langasek <email address hidden> Mon, 05 Jan 2009 10:50:10 +0000

Changed in acpi-support:
status: In Progress → Fix Released
Revision history for this message
Steve Langasek (vorlon) wrote :

The laptop-mode-tools in hardy already uses 254 by default, so no further upload of that package is needed in hardy.

Steve Langasek (vorlon)
Changed in acpi-support:
importance: Undecided → Critical
Revision history for this message
Steve Langasek (vorlon) wrote :

package uploaded to intrepid as well, waiting for review.

Changed in acpi-support:
status: Triaged → In Progress
assignee: nobody → vorlon
assignee: nobody → vorlon
status: Triaged → In Progress
Revision history for this message
Adam Porter (alphapapa) wrote :

On Mon, Jan 5, 2009 at 05:23, Steve Langasek
<email address hidden> wrote:
> The laptop-mode-tools in hardy already uses 254 by default, so no
> further upload of that package is needed in hardy.

Does that mean that all Hardy users need to do to fix this is to
enable laptop mode on AC and battery?

Revision history for this message
Steve Langasek (vorlon) wrote : Re: [Bug 59695] Re: High frequency of load/unload cycles on some hard disks may shorten lifetime

On Mon, Jan 05, 2009 at 11:50:22AM -0000, Adam Porter wrote:
> On Mon, Jan 5, 2009 at 05:23, Steve Langasek
> <email address hidden> wrote:
> > The laptop-mode-tools in hardy already uses 254 by default, so no
> > further upload of that package is needed in hardy.

> Does that mean that all Hardy users need to do to fix this is to
> enable laptop mode on AC and battery?

If you were to enable laptop mode, that would address this issue. We still
need to provide fixed packages so that this works out-of-the-box, using a
better approach than suddenly turning laptop mode on for users a year after
release.

--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer http://www.debian.org/
<email address hidden> <email address hidden>

Revision history for this message
Noel J. Bergman (noeljb) wrote :

I see that the new value is 254 from 128. An earlier suggestion had been 192, which seemed to work for me as well. Can anyone comment on the consequence of 192 vs 254? All that I have come across so far is http://ubuntuforums.org/showthread.php?t=837308 and a separate comment over at RedHat about 254 not working on one person's system (https://bugzilla.redhat.com/show_bug.cgi?id=382061#c14).

By the way, Steve, did you also just fix Bug 199094?

Revision history for this message
Adam Porter (alphapapa) wrote : Re: [Bug 59695] Re: High frequency of load/unload cycles on some hard disks may shorten lifetime

On Mon, Jan 5, 2009 at 06:10, Steve Langasek
<email address hidden> wrote:
> On Mon, Jan 05, 2009 at 11:50:22AM -0000, Adam Porter wrote:
>> On Mon, Jan 5, 2009 at 05:23, Steve Langasek
>> <email address hidden> wrote:
>> > The laptop-mode-tools in hardy already uses 254 by default, so no
>> > further upload of that package is needed in hardy.
>
>> Does that mean that all Hardy users need to do to fix this is to
>> enable laptop mode on AC and battery?
>
> If you were to enable laptop mode, that would address this issue. We still
> need to provide fixed packages so that this works out-of-the-box, using a
> better approach than suddenly turning laptop mode on for users a year after
> release.

Do you mean that laptop mode has other, undesirable consequences that
should be avoided by default? Do you know how it will be solved in
Hardy without laptop mode?

Sorry for the questions. I'm not sure if this is enough of an issue
for my laptop that I should enable laptop mode all the time, but I
think it's worth keeping an eye on it. The SMART value's percentage
is not changing that quickly, regardless of the raw value. I'm not
fully convinced, with the variations in individual drives, that anyone
really knows what the best solution is. But if you have advice, it
would be appreciated. I will probably be staying with Hardy for a
while.

Thanks for your work on this issue!

Revision history for this message
Steve Langasek (vorlon) wrote : Re: [Bug 59695] Re: High frequency of load/unload cycles on some hard disks may shorten lifetime
Download full text (3.6 KiB)

On Mon, Jan 05, 2009 at 01:41:28PM -0000, Noel J. Bergman wrote:
> I see that the new value is 254 from 128. An earlier suggestion had
> been 192, which seemed to work for me as well. Can anyone comment on
> the consequence of 192 vs 254? All that I have come across so far is
> http://ubuntuforums.org/showthread.php?t=837308 and a separate comment
> over at RedHat about 254 not working on one person's system
> (https://bugzilla.redhat.com/show_bug.cgi?id=382061#c14).

The description in the hdparm manpage is:

       -B Set Advanced Power Management feature, if the drive supports it.
              A low value means aggressive power management and a high value
              means better performance. Possible settings range from values 1
              through 127 (which permit spin-down), and values 128 through 254
              (which do not permit spin-down). The highest degree of power
              management is attained with a setting of 1, and the highest I/O
              performance with a setting of 254. A value of 255 tells hdparm
              to disable Advanced Power Management altogether on the drive
              (not all drives support disabling it, but most do).

With respect to this bug, 192 and 254 should be equivalent. 254 is
otherwise the closest approximation to 255 on systems that don't support the
255 option. (In theory, it might always be best to call hdparm -B 254
followed by hdparm -B 255, for compatibility; but that's not a change that
belongs in this SRU, either.)

I've not heard any other reports of 254 not working. As you can see, it's
documented in the manpage itself that 255 is not always supported, but I
have no reason to think 192 provides better compatibility than 254.

> By the way, Steve, did you also just fix Bug 199094?

I don't know that I would consider this a fix for 199094. It at least works
around the most significant problems described in that bug.

On Mon, Jan 05, 2009 at 03:14:33PM -0000, Adam Porter wrote:
> Do you mean that laptop mode has other, undesirable consequences that
> should be avoided by default?

Yes; there is in-line documentation in laptop-mode-tools to the effect that
enabling it causes some machines to hang on boot, at least historically; so
that's not a default that should be changed in SRU. (Even if we didn't know
of any major regression potential, turning on laptop-mode by default would
be the wrong way to fix this in SRU.)

> Do you know how it will be solved in Hardy without laptop mode?

Using the version of acpi-support that I've uploaded to hardy-proposed,
which should be available for download once another member of the ubuntu-sru
team has a chance to process it.

> Sorry for the questions. I'm not sure if this is enough of an issue
> for my laptop that I should enable laptop mode all the time, but I
> think it's worth keeping an eye on it. The SMART value's percentage
> is not changing that quickly, regardless of the raw value. I'm not
> fully convinced, with the variations in individual drives, that anyone
> really knows what the best solution is. But if you have advice, it
> would be appreciated. I will probably be staying with Hardy for a
...

Read more...

Revision history for this message
Nick B. (futurepilot) wrote :

What about cases where the 254 setting causes the hard drive to become very warm? On my laptop an hdparm value of 254 causes the hard drive to reach temperatures of around 50°C which is too high. Disabling laptop-mode allows the drive to operate in its normal range somewhere between 41-45. But then it suffers from the unload cycles. Is there another solution to this?

Revision history for this message
Endolith (endolith) wrote :

> But then it suffers from the unload cycles. Is there another
> solution to this?

Can't we just let the hard drive park and then stop writing to it for a while so it doesn't spin back up again? The main problem app for writing to the hard drive is apparently Network Manager, which craps up the system logs with useless messages several times a minute. (Bug #294190)

Surely there's a way to limit the frequency with which logs are written to the disk by buffering them in memory first?

Revision history for this message
Hanno Stock (hefe_bia) (hanno-stock) wrote : Re: [Bug 59695] Re: High frequency of load/unload cycles on some hard disks may shorten lifetime

Nick B. schrieb:
> What about cases where the 254 setting causes the hard drive to become
> very warm? On my laptop an hdparm value of 254 causes the hard drive to
> reach temperatures of around 50°C which is too high. Disabling laptop-
> mode allows the drive to operate in its normal range somewhere between
> 41-45. But then it suffers from the unload cycles. Is there another
> solution to this?

I have exactly the same problem. You might try other values close to 254
and monitor your load cycles. Maybe you're lucky and the drive firmware
has a setting where the time until the heads are parked is moderately
high so parking will occur less often.
Otherwise I would complain to the drive manufacturer or laptop
manufacturer. (I think one can expect a hard drive to be operable with
constant but little disk activity without wearing off way before the
expected life span...)

Regards, Hanno

Revision history for this message
Adam Porter (alphapapa) wrote : Re: [Bug 59695] Re: High frequency of load/unload cycles on some hard disks may shorten lifetime

On Mon, Jan 5, 2009 at 14:38, Endolith <email address hidden> wrote:
>> But then it suffers from the unload cycles. Is there another
>> solution to this?
>
> Can't we just let the hard drive park and then stop writing to it for a
> while so it doesn't spin back up again? The main problem app for
> writing to the hard drive is apparently Network Manager, which craps up
> the system logs with useless messages several times a minute. (Bug
> #294190)
>
> Surely there's a way to limit the frequency with which logs are written
> to the disk by buffering them in memory first?

That is strange. I'm on Hardy using wifi and Network Manager goes
hours between log writes. I checked $(sudo grep network /var/log/*).
I have a Dell M1330 with iwl4965 using the iwlagn 2.3.5kds module.

Revision history for this message
Cesar Arguinzones (ceap80) wrote :

I have same problem as endolith. But as long as my laptop is not having
problems, i'm not interested in
any type of logs. Is there a way to disable ALL logging in ubuntu?

On Mon, Jan 5, 2009 at 4:40 PM, Adam Porter <email address hidden> wrote:

> On Mon, Jan 5, 2009 at 14:38, Endolith <email address hidden> wrote:
> >> But then it suffers from the unload cycles. Is there another
> >> solution to this?
> >
> > Can't we just let the hard drive park and then stop writing to it for a
> > while so it doesn't spin back up again? The main problem app for
> > writing to the hard drive is apparently Network Manager, which craps up
> > the system logs with useless messages several times a minute. (Bug
> > #294190)
> >
> > Surely there's a way to limit the frequency with which logs are written
> > to the disk by buffering them in memory first?
>
> That is strange. I'm on Hardy using wifi and Network Manager goes
> hours between log writes. I checked $(sudo grep network /var/log/*).
> I have a Dell M1330 with iwl4965 using the iwlagn 2.3.5kds module.
>
> --
> High frequency of load/unload cycles on some hard disks may shorten
> lifetime
> https://bugs.launchpad.net/bugs/59695
> You received this bug notification because you are a direct subscriber
> of the bug.
>

--
Cesar Arguinzones

Revision history for this message
Martin Pitt (pitti) wrote : Re: [Bug 59695] Re: High frequency of load/unload cycles on some hard disks may shorten lifetime

Hi Cesar,

Cesar Arguinzones [2009-01-05 22:32 -0000]:
> I have same problem as endolith. But as long as my laptop is not having
> problems, i'm not interested in
> any type of logs. Is there a way to disable ALL logging in ubuntu?

I'd strongly advise against disabling *all* logging, but you can
change /etc/syslog.conf to only log messages with levels "error" and
above, which will ignore all the debug/info/warning stuff.

See "man syslog.conf" for details.

Revision history for this message
Martin Pitt (pitti) wrote :

Accepted acpi-support into intrepid-proposed, please test and give feedback here. Please see https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Thank you in advance!

Changed in acpi-support:
status: In Progress → Fix Committed
milestone: ubuntu-8.04.2 → none
status: In Progress → Fix Committed
Revision history for this message
Martin Pitt (pitti) wrote :

Accepted acpi-support into hardy-proposed, please test and give feedback here. Please see https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Thank you in advance!

Revision history for this message
midnightflash (midnightflash) wrote :

The (intrepid) proposed-version of acpi-support seems to work fine for me now.
Thanks for now.

Steve Langasek (vorlon)
Changed in acpi-support:
milestone: none → ubuntu-8.04.2
Revision history for this message
Ciso (cisoprogressivo) wrote :

So to check if the patch works what I need?
Only the "proposed" acpi-support package and to enable by hand the laptop-mode?

Revision history for this message
Steve Langasek (vorlon) wrote :

On Tue, Jan 06, 2009 at 08:23:35PM -0000, Ciso wrote:
> So to check if the patch works what I need?
> Only the "proposed" acpi-support package and to enable by hand the
> laptop-mode?

No. You need to install the -proposed acpi-support package and restart your
system for the changed settings to take effect. You should *not* need to
enable laptop-mode to see the effects of this bugfix.

--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer http://www.debian.org/
<email address hidden> <email address hidden>

Revision history for this message
Adam Porter (alphapapa) wrote : Re: [Bug 59695] Re: High frequency of load/unload cycles on some hard disks may shorten lifetime

On Tue, Jan 6, 2009 at 15:06, Steve Langasek
<email address hidden> wrote:
> On Tue, Jan 06, 2009 at 08:23:35PM -0000, Ciso wrote:
>> So to check if the patch works what I need?
>> Only the "proposed" acpi-support package and to enable by hand the
>> laptop-mode?
>
> No. You need to install the -proposed acpi-support package and restart your
> system for the changed settings to take effect. You should *not* need to
> enable laptop-mode to see the effects of this bugfix.

Just FYI, when I installed the package from -proposed, I noticed the
postinst script restarting the ACPI stuff in /etc/init.d and saw it
set the PM mode then. Is a restart still necessary?

Revision history for this message
Steve Langasek (vorlon) wrote : Re: [Bug 59695] Re: High frequency of load/unload cycles on some hard disks may shorten lifetime

On Tue, Jan 06, 2009 at 09:21:22PM -0000, Adam Porter wrote:
> Just FYI, when I installed the package from -proposed, I noticed the
> postinst script restarting the ACPI stuff in /etc/init.d and saw it
> set the PM mode then. Is a restart still necessary?

Oh, I didn't think about this aspect. Yes, the restart appears to apply the
settings from either /etc/acpi/battery.d or /etc/acpi/ac.d, so should set
the hdparm setting correctly.

--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer http://www.debian.org/
<email address hidden> <email address hidden>

Steve Langasek (vorlon)
description: updated
Revision history for this message
Tormod Volden (tormodvolden) wrote :

I can confirm success of the intrepid-proposed package. My Load_Cycle_Count / Power_On_Hours was 177 (ca 3 per minute) after 2 months of use (mostly using Intrepid). I went through the Test Case 1-4, 6, 7, 5, 4, 6.

Revision history for this message
Babyshamble (babyshamble) wrote : Re: [Bug 59695] Re: High frequency of load/unload cycles on some hard disks may shorten lifetime
Download full text (8.6 KiB)

I can also confirm that the Intrepid-proposed package it's working without
any problem. The load_cycle at my HP 6720s laptop stopped the insane
increase rage when using the battery power.

However I still have concerns about the mechanism used to fix this bug. It
would be possible that ubuntu devs make a wiki page explaining whatever they
did in a clean and simple language? It can also used to explain to regular
people (or at least users not familiar with this problem) what happened and
what's going on since the release of this fix.

On Wed, Jan 7, 2009 at 6:26 PM, Tormod Volden <email address hidden>wrote:

> I can confirm success of the intrepid-proposed package. My
> Load_Cycle_Count / Power_On_Hours was 177 (ca 3 per minute) after 2
> months of use (mostly using Intrepid). I went through the Test Case 1-4,
> 6, 7, 5, 4, 6.
>
> --
> High frequency of load/unload cycles on some hard disks may shorten
> lifetime
> https://bugs.launchpad.net/bugs/59695
> You received this bug notification because you are a direct subscriber
> of the bug.
>
> Status in The Dell Project: Confirmed
> Status in "acpi-support" source package in Ubuntu: Fix Released
> Status in "linux-meta" source package in Ubuntu: New
> Status in "pm-utils" source package in Ubuntu: New
> Status in acpi-support in Ubuntu Hardy: Fix Committed
> Status in linux-meta in Ubuntu Hardy: New
> Status in pm-utils in Ubuntu Hardy: New
> Status in acpi-support in Ubuntu Intrepid: Fix Committed
> Status in linux-meta in Ubuntu Intrepid: New
> Status in pm-utils in Ubuntu Intrepid: New
> Status in "acpi-support" source package in Baltix: New
> Status in "acpi-support" source package in Debian: Fix Released
> Status in "pm-utils" source package in Fedora: Invalid
> Status in "laptop-mode-tools" source package in Mandriva: Confirmed
> Status in Suse Linux: Fix Released
>
> Bug description:
> This is not a support forum. Please do not use it as such (even though it
> has been used as such already).
>
> You can scan through the bug for links to the Ubuntu forums where many,
> many different questions have been asked, answered, and re-answered. The
> temporary workaround is just below.
>
> See https://wiki.ubuntu.com/PowerManagement for an overview about what is
> involved and for a remedy.
>
> SRU justification: current behavior may lead to premature disk failure in
> laptops due to excessive unnecessary drive parking. Fix will disable disk
> cycling by default when on AC power, by correcting an error in the hdparm
> logic of acpi-support.
>
> For jaunty, this issue is addressed in acpi-support 0.115.
>
> TEST CASE:
>
> 1. With acpi-support 0.109 (hardy) or 0.114 (intrepid) installed and
> laptop-mode *not* enabled in either /etc/default/laptop-mode or
> /etc/default/acpi-support, monitor the load cycle count of your hard drive
> by running 'sudo smartctl -a /dev/sda|grep Load_Cycle_Count' over an
> interval of several minutes, and observe that it is incrementing. (If it
> does not increment, your hard drive's manufacturer defaults are sane and you
> are not affected by this problem.)
> 2. install acpi-support from hardy-proposed or intrepid-proposed
> 3. while connected to AC power, mon...

Read more...

Revision history for this message
Endolith (endolith) wrote :

I'm seeing about 0.5 load cycles per hour now, so this is no longer a problem for me using acpi-support 0.114-0intrepid1 from Proposed. It's too late for my current hard drive (1,351,794 load cycles), but at least I won't have to worry about the replacement dying young, too. :) Thank you!

description: updated
Revision history for this message
Paganini (nebanks) wrote :

Well, sadly, the new acpi-support has not fixed things for my X40. It has a Hitachi drive, Model Number: HTC426040G9AT00. Even with the least aggressive settings (-B 255 and -B 254) it still parks the heads more than once a minute. As far as I can tell, the settings "took" -- hdparm -I shows the correct APM level -- but the drive just ignores them. Hitachi's disk tool doesn't support this drive, so I can't hand-edit the firmware.

Is there any hope, or am I doomed to watch my basically new hard disk chew itself up and die?

Revision history for this message
Steve Langasek (vorlon) wrote : Re: [Bug 59695] Re: High frequency of load/unload cycles on some hard disks may shorten lifetime

On Thu, Jan 08, 2009 at 07:24:51PM -0000, Paganini wrote:

> Is there any hope, or am I doomed to watch my basically new hard disk
> chew itself up and die?

If 'Advanced power management level' is correctly set to 254 on your drive,
and it's still parking, then I'm afraid I don't see anything else we can do
this to fix this from Ubuntu. My understanding is that '254' means, by
definition, that the heads are not supposed to be parked; so you appear to
have buggy firmware. You might have luck with talking to your vendor about
a firmware fix for the drive?

--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer http://www.debian.org/
<email address hidden> <email address hidden>

Revision history for this message
Steve Langasek (vorlon) wrote :

Thanks to all who have helped verify that this fix is correct for intrepid. Are there any users following this bug who are using hardy? Since 8.04 is an LTS release, it stands to reason that there are some users who might like to ensure their hard drives outlast the 3-year desktop support cycle, so I would very much like us to be able to roll this fix into the upcoming 8.04.2 point release.

Revision history for this message
Steve Langasek (vorlon) wrote :

Babyshamble,

https://bugs.launchpad.net/ubuntu/hardy/+source/acpi-support/+bug/59695/comments/652 includes a description of what the additional fix was that was needed here. Is that what you're looking for?

Revision history for this message
Adam McGreggor (adam-amyl) wrote : Re: [Bug 59695] Re: High frequency of load/unload cycles on some hard disks may shorten lifetime

On Fri, Jan 09, 2009 at 01:46:54AM -0000, Steve Langasek wrote:
> Thanks to all who have helped verify that this fix is correct for
> intrepid. Are there any users following this bug who are using hardy?

Yeap ;)

> Since 8.04 is an LTS release, it stands to reason that there are some
> users who might like to ensure their hard drives outlast the 3-year
> desktop support cycle, so I would very much like us to be able to roll
> this fix into the upcoming 8.04.2 point release.

Might have a chance mid-late next week, to test (although I may need to
revert to pre-hackery... don't think i repo'd these changes).

Revision history for this message
Michał Gołębiowski-Owczarek (mgol) wrote :

> Are there any users following this bug who are using hardy?

Me, for example. What could I do? Any instructions how to test this update? Thanks. :)

Revision history for this message
Noel J. Bergman (noeljb) wrote :

Steve, I have Hardy, Intrepid and Jaunty. Will be happy to test against Hardy for you. What do you need? :-)

Revision history for this message
Steve Langasek (vorlon) wrote : Re: [Bug 59695] Re: High frequency of load/unload cycles on some hard disks may shorten lifetime

On Fri, Jan 09, 2009 at 02:33:04AM -0000, Michał Gołębiowski wrote:
> > Are there any users following this bug who are using hardy?

> Me, for example. What could I do? Any instructions how to test this
> update? Thanks. :)

The test case is in the bug description, and instructions on enabling the
-proposed repo are at <https://wiki.ubuntu.com/Testing/EnableProposed>.
Please report back here with the results of your testing (positive or
negative).

Thanks,
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer http://www.debian.org/
<email address hidden> <email address hidden>

Revision history for this message
Adam Porter (alphapapa) wrote : Re: [Bug 59695] Re: High frequency of load/unload cycles on some hard disks may shorten lifetime

I'm on Hardy and I've noticed that since installing the new package,
the Start_Stop_Count on my Samsung drive has stopped increasing at
all. Seems to work fine.

On Thu, Jan 8, 2009 at 21:50, Steve Langasek
<email address hidden> wrote:
> On Fri, Jan 09, 2009 at 02:33:04AM -0000, Michał Gołębiowski wrote:
>> > Are there any users following this bug who are using hardy?
>
>> Me, for example. What could I do? Any instructions how to test this
>> update? Thanks. :)
>
> The test case is in the bug description, and instructions on enabling the
> -proposed repo are at <https://wiki.ubuntu.com/Testing/EnableProposed>.
> Please report back here with the results of your testing (positive or
> negative).
>
> Thanks,
> --
> Steve Langasek Give me a lever long enough and a Free OS
> Debian Developer to set it on, and I can move the world.
> Ubuntu Developer http://www.debian.org/
> <email address hidden> <email address hidden>
>
> --
> High frequency of load/unload cycles on some hard disks may shorten lifetime
> https://bugs.launchpad.net/bugs/59695
> You received this bug notification because you are a direct subscriber
> of the bug.
>

Revision history for this message
Ciso (cisoprogressivo) wrote :

Unfortunately I don't have the Start_Stop_Count value, but I'm sure that my HD is affected by this bug (I can hear the click).
It's a Dell XPS M1330 with the 400gb HD.
On Battery it seems that nothing changes? Is it correct?
I see that on battery the bug seems solved only for someone. In the description I can see the Start_Stop_Count stops increase only on AC, but why it stops increasing on battery for someone?
Sorry for my English.

Revision history for this message
Ciso (cisoprogressivo) wrote :

I use KDE, is this changing something?

Revision history for this message
bojo42 (bojo42) wrote :

@Steve: For Intrepid i can confirm that the proposed package works, even on suspend. Although /etc/acpi/resume.d/90-hdparm.sh still don't get executed, the scripts in ac.d and battery.d handle changing power states on suspend very well. This means we don't need a link in /etc/pm/sleep.d/ for this fixes working at suspend, like i mentioned before.

Revision history for this message
Steve Langasek (vorlon) wrote :

Ciso,

On battery the default value is still hdparm -B 128, which does allow the drive to park the heads. This upload only changes the default policy when running on AC.

For some drives, it's possible that the -B 128 battery policy is different than the firmware default and as a result the drive has a longer idle time between parking; this will not be true /generally/, and is a largely harmless side effect of the change rather than a deliberate bugfix.

Revision history for this message
Tormod Volden (tormodvolden) wrote :

I have tested the 0.109-0hardy1 from hardy-proposed on a couple of laptops. (One had a count of 300000, I had it running continuously on AC for a couple of months. Bad.) The count is now stopped while on AC. It increases on battery even if I have laptop_mode enabled. BTW, what it exactly the function of point 5 in the test case? Shouldn't 6 and 7 work without 5 anyway?

While testing all this I had a bad crash with ata errors flowing in /proc/kmsg. I had to alt-sysrq-S-U-B and there's not much written in kern.log. Maybe this happened because of smartctl (I was running it with and without -d ata, and also on a WD drive over USB which didn't work), or because I already had laptop_mode enabled and a test version of acpi-support installed (both disabled/reverted before I did the test case though). It happened shortly after unplugging AC and running smartctl which hung. I hope it's only me and bad luck.

I think this is the single most important SRU I ever installed. Steve, thanks so much for sorting this out. I hope you will attack the whole acpi-support vs laptop-mode-tools and pm-utils interaction (mess?) while you're at it...

Revision history for this message
Nick B. (futurepilot) wrote :

I just updated acpi-support to the Intrepid Proposed version and it stops my load cycle count from increasing, however it causes my hard drive to become very warm.

Revision history for this message
Tormod Volden (tormodvolden) wrote :

I said "it increases on battery even if I have laptop_mode enabled". This was due to having firefox open. Without firefox, on battery, with laptop_mode enabled, it only increases very slowly, like it is supposed to do.

However, after plugging in AC again it keeps increasing. This might be the fault of laptop_mode. Since I was involved in some laptop-mode-tools development and testing on this laptop some time ago, there is a chance there is something I have forgotten to revert back to default, so I would be thankful if someone else can verify this on Hardy.

Revision history for this message
Alexey Borzenkov (snaury) wrote :

> However, after plugging in AC again it keeps increasing.

Laptop mode is enabled only on battery by default, you need to explicitly enable it in /etc/laptop-mode/laptop-mode.conf for both battery and ac, if you want that.

Revision history for this message
Paganini (nebanks) wrote :

For those of us with crazy drives like mine that park whenever APM times out no matter what, I have a possible partial solution.

It seems that what is happening is that the drive's timeout for parking the heads is shorter than the interval at which ubuntu syncs the filesystem to disk. This means that any kind of filesystem activity (such as regular touches or a big download) are insufficient to keep the heads from parking.

However, smartctl talks directly to the disk itself. From experimenting this afternoon, calling smartctl -a every 15 seconds keeps the disk awake. This did cause the disk to heat up to 42c, which is 3 or 4 degrees hotter than it normally runs.

I wrote a script with an infinite while loop to keep calling smartctl every 15 seconds. Unfortunately this script causes my system to hang if it is running when I shutdown. I am pretty noob at scripting. Maybe someone with more script-fu could contact me privately to help iron out this problem?

Revision history for this message
Nick B. (futurepilot) wrote :

Oops, I think I found a regression. The proposed version of acpi-support seems to break resume from suspend only when invoked from Gnome-power-manager. On resume it seems to hang and the screen never turns back on. Downgrading to the original version of acpi-support (0.114) has no issues with suspend. However suspending it from FUSA or the System menu has no problem with either version of acpi-support. This is on Intrepid.

Revision history for this message
Adam Porter (alphapapa) wrote :

On Fri, Jan 9, 2009 at 20:19, Nick B. <email address hidden> wrote:
> Oops, I think I found a regression. The proposed version of acpi-support
> seems to break resume from suspend only when invoked from Gnome-power-
> manager. On resume it seems to hang and the screen never turns back on.
> Downgrading to the original version of acpi-support (0.114) has no
> issues with suspend. However suspending it from FUSA or the System menu
> has no problem with either version of acpi-support. This is on Intrepid.

Are you absolutely sure that's caused by this package? Sometimes my
Hardy system also fails to resume from suspend with the screen never
turning on, but it's always done that, and I still don't know why.

Revision history for this message
Nick B. (futurepilot) wrote :

I am very sure. I've never had a problem with suspend on Intrepid. It's always worked perfectly. After updating acpi-support it doesn't resume properly after invoked from the power manager. I downgrade the package and it works fine again.

Revision history for this message
Steve Langasek (vorlon) wrote : Re: [Bug 59695] Re: High frequency of load/unload cycles on some hard disks may shorten lifetime

On Sat, Jan 10, 2009 at 03:41:18AM -0000, Nick B. wrote:
> I am very sure. I've never had a problem with suspend on Intrepid. It's
> always worked perfectly. After updating acpi-support it doesn't resume
> properly after invoked from the power manager. I downgrade the package
> and it works fine again.

But is the problem reproducible again if you re-upgrade?

The code that acpi-support runs on resume as a result of this update is:

  # Get the power state into STATE
  getState;

  for dev in /dev/sd? /dev/hd? ; do
    if [ -b $dev ] ; then
      # Check for APM support; discard errors since not all drives
      # support HDIO_GET_IDENTITY (-i).
      if hdparm -i $dev 2> /dev/null | grep -q 'AdvancedPM=yes' ; then
        if [ $STATE = "BATTERY" ] ; then
          hdparm -B 128 $dev
        else
          hdparm -B 254 $dev
        fi
      fi
    fi
  done

it's not clear to me why any of this should trigger a hang on resume. Are
you knowledgeable with shell that you could try commenting out parts of this
code in /etc/acpi/resume.d/90-hdparm.sh, to find out which part is
responsible for the hang?

--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer http://www.debian.org/
<email address hidden> <email address hidden>

Revision history for this message
Nick B. (futurepilot) wrote :

Yes, after upgrading the package after a downgrade it is reproducible. I will try and play around with that code to see if I can pinpoint it.

Revision history for this message
Nick B. (futurepilot) wrote :

Actually I think I figured out what the problem was and it was not this package. Sorry for the confusion.

Revision history for this message
Jan Mynarik (jan-mynarik) wrote :

Nick B.: I have similar resume problem (and no problem earlier). Could you help me? E.g. point me to different bug? Thanks.

Revision history for this message
Noel J. Bergman (noeljb) wrote :

Seems to work for me with Hardy, as well. I installed it last night. So Hard,y Intrepid and Jaunty all seem OK on my end.

Revision history for this message
Michał Gołębiowski-Owczarek (mgol) wrote :

@ Steve Langasek
I tried it. I wrote a script that checks the Load_Cycle_Count number and writes with the actual date to the log file. I executed this script periodically (and between those executions I did nothing), and this is the output:

### AC ON
09.01.11 05:24:39 116203
### AC OFF
09.01.11 05:25:17 116208

It worried me a lot, as in 30 seconds it raised by 5! I thought it's not fixed. Though later...

09.01.11 05:26:41 116216
09.01.11 05:27:22 116217
09.01.11 05:28:49 116217
09.01.11 05:29:31 116217
09.01.11 05:36:09 116217
09.01.11 05:48:03 116217
09.01.11 05:56:22 116217
### AC ON
09.01.11 05:56:36 116217
09.01.11 05:57:22 116217
09.01.11 06:06:02 116217
### AC OFF
09.01.11 06:07:07 116217
09.01.11 06:15:37 116217

reboot...

### AC ON
09.01.11 06:26:56 116219
### AC OFF
09.01.11 06:27:20 116219
09.01.11 06:42:20 116219

As You can see, later even after 25 (sic!) minutes of not doing nothing the counter didn't raise even once.

So there are 2 questions:
1) Why the counter raised so quickly at the first time I unplugged AC power? Is it normal?
2) Shouldn't my HDD park at least once per 15 minutes? I thought that a fix should make parking less often, but not to switch it off completely...

Or maybe I'm wrong and it's ok? Waiting for Your opinions...

Revision history for this message
Michał Gołębiowski-Owczarek (mgol) wrote :

Just to mention it: I checked the version from hardy-proposed, I suppose this was the right one?

Revision history for this message
Tobias Stegmann (punischdude) wrote :

When resuming from S2R the script is not being executed in hardy cause of this issue: https://bugs.launchpad.net/ubuntu/+source/acpi-support/+bug/205005/comments/2

I had to install it to /etc/pm/sleep.d to get it working.

Revision history for this message
Vincenzo Ciancia (vincenzo-ml) wrote :

This bug is _not_ fixed for me in up-to-date intrepid with the -proposed repository enabled. I log cycles and temperature using the script that I attached to this bug

http://launchpadlibrarian.net/20449344/watch_load_cycles

This morning, I had 135 cycles in one hour. Smartctl reports the following identification for my disk:

=== START OF INFORMATION SECTION ===
Model Family: Hitachi Travelstar 5K100 series
Device Model: HTS541080G9SA00
Serial Number: MPBDL0XKGB63RG
Firmware Version: MB4OC60R
User Capacity: 80,026,361,856 bytes
Device is: In smartctl database [for details use: -P show]
ATA Version is: 7
ATA Standard is: ATA/ATAPI-7 T13 1532D revision 1
Local Time is: Mon Jan 12 21:42:35 2009 CET
SMART support is: Available - device has SMART capability.
SMART support is: Enabled

I had to re-enable a periodic (every 5 minutes) use of hdparm -b 200. Using 254 seems ok to me, but sometimes it seems like intrepid is _not_ setting this value at the right point. I use suspend-to-ram and suspend-to-disk regularly.

Revision history for this message
Jakob Unterwurzacher (jakobunt) wrote :

Reading all the applause makes me think i am doing something wrong. But:

For me (Intrepid+proposed), this does not fix the issue.
Suspend to ram -> resume gives me an APM level of 128.

Switching from battery to ac power does set apm 254 - it's the same script doing that, so it's not my wrong laptop-mode config.

I don't get how a script in /etc/acpi/resume.d could fix this at all - this folder is not used anymore, see bug #223879 .

Revision history for this message
bojo42 (bojo42) wrote :

@Jakob: When you have problems with suspend, just you link /etc/acpi/resume.d/90-hdparm.sh in /etc/pm/sleep.d/:

sudo ln -s /etc/acpi/resume.d/90-hdparm.sh /etc/pm/sleep.d/

And yes this is a somewhat misleading bug.

Revision history for this message
Jakob Unterwurzacher (jakobunt) wrote :

@bojo: This is not a good solution, because sleep.d scripts should accepts some command line arguments - see /usr/share/doc/pm-utils/HOWTO.hooks .

A good solution would be to write a script that does the hdparm-thingy and respects the pm-utils semantics. I created one, it is attached.
Copy it to /usr/lib/pm-utils/sleep.d/95hdparm-apm , chmod +x and chown root:root it. For me it works flawlessly.

Dear Steve Langasek: This bug isn't fixed until this script (or something similar) is included in pm-utils.

Revision history for this message
Colin Watson (cjwatson) wrote :

After reviewing this bug and bug 223879, I agree that pm-utils needs to be fixed too (and confirmed that with Steve Langasek on IRC).

Nevertheless, notwithstanding some side-effects on certain pieces of hardware that are probably not entirely resolvable, I think that the acpi-support package in hardy-proposed is on balance a significant improvement. It is true that until pm-utils is fixed, power management will be reset on suspend/resume; nevertheless this is better than it being wrong across the board.

I've raised the priority of the pm-utils task on this bug as high as it will go, assigned it to Steve, and targeted it for 8.04.3. I expect that it can in fact be dealt with well before that.

Changed in pm-utils:
assignee: nobody → vorlon
importance: Undecided → Critical
milestone: none → ubuntu-8.04.3
status: New → Triaged
Revision history for this message
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package acpi-support - 0.109-0hardy1

---------------
acpi-support (0.109-0hardy1) hardy-proposed; urgency=low

  * Cherry-pick hdparm fixes from intrepid:
    - ac.d/90-hdparm.sh, battery.d/90-hdparm.sh, resume.d/90-hdparm.sh,
      start.d/90-hdparm.sh: Set hdparm power management to 254 for all
      hard drives, ignoring errors while detecting if APM is supported.
      Set hdparm -B 128 while on battery, because head parking is useful
      on the road for shock protection.
    - power.sh: use 254 instead of 255 also when laptop mode is in use;
      this handling is obsoleted entirely in intrepid and beyond, but
      we'll take a minimally-intrusive fix for hardy.
    LP: #59695.

 -- Steve Langasek <email address hidden> Mon, 05 Jan 2009 10:33:13 +0000

Changed in acpi-support:
status: Fix Committed → Fix Released
Revision history for this message
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package acpi-support - 0.114-0intrepid1

---------------
acpi-support (0.114-0intrepid1) intrepid-proposed; urgency=low

  * {ac,battery,resume,start}.d/90-hdparm.sh: don't just check whether
    laptop-mode is configured to control the drives, also check whether
    laptop-mode itself is *enabled*. Finally closes LP: #59695.

 -- Steve Langasek <email address hidden> Mon, 05 Jan 2009 10:50:10 +0000

Changed in acpi-support:
status: Fix Committed → Fix Released
Revision history for this message
Colin Watson (cjwatson) wrote :

Note that, despite the automatic bug-closing messages above, this bug is still open on pm-utils.

Revision history for this message
Steve Langasek (vorlon) wrote :

On Fri, Jan 09, 2009 at 09:37:19PM -0000, Tormod Volden wrote:
> I have tested the 0.109-0hardy1 from hardy-proposed on a couple of
> laptops. (One had a count of 300000, I had it running continuously on AC
> for a couple of months. Bad.) The count is now stopped while on AC. It
> increases on battery even if I have laptop_mode enabled. BTW, what it
> exactly the function of point 5 in the test case? Shouldn't 6 and 7 work
> without 5 anyway?

The point is to make sure there are no interactions that cause a regression
when laptop-support is enabled.

Cheers,
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer http://www.debian.org/
<email address hidden> <email address hidden>

Revision history for this message
Ralph Corderoy (ralph-inputplus) wrote :

After installing acpi-support 0.109-0hardy1 this morning on 8.04, the motherboard's drive LED on the case stayed on. Executing a `hdparm -B 254 /dev/sdb' half an hour later turned it off. /var/log/apt/term.log shows

    * Checking battery state...
   /dev/sdb:
    setting Advanced Power Management level to 0x80 (128)

and hdparm -I confirmed this was the setting while the LED was stuck on. This is not a laptop; there's no battery and I don't want a -B of 128 but 254. It seems the scripts don't distinguish between on_ac_power(1) returning 1, we know system is not on mains, and 255, we couldn't find out either way. On this machine,

    $ on_ac_power; echo $?
    255

I think it should err on the side of this probably not being a laptop with a battery if the hardware is such, e.g. old, that on_ac_power returns 255.

Revision history for this message
Ralph Corderoy (ralph-inputplus) wrote :

There's further problems that need fixing.
/etc/acpi/start.d/90-hdparm.sh uses getState() from
/usr/share/acpi-support/power-funcs to set STATE. 90-hdparm.sh says if
$STATE is BATTERY then -B 128 else -B 254. That's fine. But
power-funcs has

    getState() {
            /usr/bin/on_ac_power;
            if [ "$?" -eq 0 ]; then
                    STATE="AC";
            elif [ "$?" -eq 1 ]; then
                    STATE="BATTERY";
            fi
    }

(Ignore the trailing semi-colons.)

/usr/bin/on_ac_power(1) defines its exit value as 0, 1, or 255. 0 =
mains. 1 = not mains. 255 = could not be determined. The above code
doesn't save $? after running on_ac_power so the first test, whether it
is 0, tramples $? by the time the elif test is run. Here's the `sh -x'
output.

    + /usr/bin/on_ac_power
    + '[' 255 -eq 0 ']'
    + '[' 1 -eq 1 ']'
    + STATE=BATTERY

See how the 255 from on_ac_power has been trampled to 1. So when
on_ac_power exits non-0 we have STATE=BATTERY. Here's one possible fix.

    getState() {
        /usr/bin/on_ac_power
        case $? in
        0) STATE=AC;;
        1) STATE=BATTERY;; # Strictly, not mains.
        *) STATE=UNKNOWN;; # 255 and future ones.
        esac
    }

It's because STATE is erroneously being set to BATTERY that 90-hdparm.sh
is using -B 128:

      if hdparm -i $dev 2> /dev/null | grep -q 'AdvancedPM=yes' ; then
        if [ $STATE = "BATTERY" ] ; then
          hdparm -B 128 $dev
        else
          hdparm -B 254 $dev
        fi
      fi

Fix that, and I return to 254, avoiding the `excessive head load/unload
cycles' 90-hdparm.sh warns against.

As it stands getState() is badly broken causing BATTERY behaviour on
desktop machines.

Revision history for this message
Jakob Unterwurzacher (jakobunt) wrote :

There are two bugs:

One in power-funcs.sh :

if [ "$?" -eq 0 ]; then
                    STATE="AC";
elif [ "$?" -eq 1 ]; then

This is wrong because the first test [ "$?" -eq 0 ] will change $? .
We need to save $? to another variable before testing it. The attached patch does that.

Revision history for this message
Jakob Unterwurzacher (jakobunt) wrote :

The other on in 90-hdparm.sh :

if [ $STATE = "BATTERY" ] ; then

causes a syntax error when $STATE is empty (it is empty when on_ac_power didn't return either 0 or 1). We need to quote $STATE. The attached patch does that.

Revision history for this message
Steve Langasek (vorlon) wrote :

Ralph, Jakob, thank you for the analysis. I've prepared a new upload of acpi-support to hardy-proposed, and will work on fixing this for intrepid and jaunty shortly.

Changed in acpi-support:
status: Fix Released → In Progress
status: Fix Released → Triaged
Steve Langasek (vorlon)
Changed in acpi-support:
status: Fix Released → Triaged
Revision history for this message
Colin Watson (cjwatson) wrote :

Accepted acpi-support into hardy-proposed, please test and give feedback here. Please see https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Thank you in advance!

Changed in acpi-support:
milestone: ubuntu-8.04.2 → none
status: In Progress → Fix Committed
Revision history for this message
Colin Watson (cjwatson) wrote :

Accepted acpi-support into intrepid-proposed, please test and give feedback here. Please see https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Thank you in advance!

Changed in acpi-support:
status: Triaged → Fix Committed
Revision history for this message
Jakob Unterwurzacher (jakobunt) wrote :

acpi-support 0.109-0hardy2 fixes this for me.

Tests conducted:
1) on_ac_power returns 255
=> apm 254
2) on_ac_power returns 0
=> apm 254
3) on_ac_power returns 1
=> apm 128

Revision history for this message
Jakob Unterwurzacher (jakobunt) wrote :

acpi-support 0.114-0intrepid2 fixes this on my intrepid machine.

Tests conducted:
1) on_ac_power returns 255
=> apm 254
2) on_ac_power returns 0
=> apm 254
3) on_ac_power returns 1
=> apm 128

(the files 90-hdparm.sh and power-funcs are the same as in 0.109-0hardy2 as verified by md5sum comparison, so this isn't too surprising)

Revision history for this message
Bart Samwel (bart-samwel) wrote : Re: [Bug 59695] Re: High frequency of load/unload cycles on some hard disks may shorten lifetime

Hi Steve,

Steve Langasek wrote:
> Ralph, Jakob, thank you for the analysis. I've prepared a new upload of
> acpi-support to hardy-proposed, and will work on fixing this for
> intrepid and jaunty shortly.
>
> ** Changed in: acpi-support (Ubuntu Hardy)
> Status: Fix Released => In Progress
>
> ** Changed in: acpi-support (Ubuntu Intrepid)
> Status: Fix Released => Triaged
>
> ** Changed in: acpi-support (Ubuntu)
> Status: Fix Released => Triaged

BTW, note that this was fixed in the Debian version of acpi-support
(which I maintain) some time ago. Since I've noted that some of the
other changes from Debian have already found their way into the Ubuntu
version, I thought perhaps you might be interested in syncing this as well.

Cheers,
Bart

Revision history for this message
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package acpi-support - 0.109-0hardy2

---------------
acpi-support (0.109-0hardy2) hardy-proposed; urgency=low

  [ Jakob Unterwurzacher ]
  * Defensive quoting in 90-hdparm.sh, so that the script doesn't throw
    a syntax error when the battery state is undetermined.

  [ Steve Langasek ]
  * lib/power-funcs: refactor getState() to return 'AC' by default,
    since this is implicitly the case if we don't have a battery.
    LP: #59695.

 -- Steve Langasek <email address hidden> Thu, 15 Jan 2009 13:06:55 +0000

Changed in acpi-support:
status: Fix Committed → Fix Released
Revision history for this message
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package acpi-support - 0.114-0intrepid2

---------------
acpi-support (0.114-0intrepid2) intrepid-proposed; urgency=low

  [ Jakob Unterwurzacher ]
  * Defensive quoting in 90-hdparm.sh, so that the script doesn't throw
    a syntax error when the battery state is undetermined.

  [ Steve Langasek ]
  * lib/power-funcs: refactor getState() to return 'AC' by default,
    since this is implicitly the case if we don't have a battery.
    LP: #59695.

 -- Steve Langasek <email address hidden> Thu, 15 Jan 2009 13:37:16 +0000

Changed in acpi-support:
status: Fix Committed → Fix Released
Revision history for this message
Colin Watson (cjwatson) wrote :

Due to successful testing, I'm copying the new acpi-support uploads to hardy-updates and intrepid-updates now, waiving the usual delay period since this was an update regression.

Revision history for this message
Vincenzo Ciancia (vincenzo-ml) wrote :

On 14/01/2009 Jakob Unterwurzacher wrote:
> For me (Intrepid+proposed), this does not fix the issue.
> Suspend to ram -> resume gives me an APM level of 128.

Jakob: how can you read APM levels? I think this is my problem too.

Vincenzo

Revision history for this message
Ralph Corderoy (ralph-inputplus) wrote : Re: [Bug 59695] Re: High frequency of load/unload cycles on some hard disks may shorten lifetime

Vincenzo, `sudo hdparm -I /dev/sda' and look for the line like

    Advanced power management level: 64

Some drives don't have `Advanced Power Management feature set' in their
`Commands/features' list that's also in -I's output so you won't see a
reading for it.

Revision history for this message
Jakob Unterwurzacher (jakobunt) wrote :

On 14/01/2009 Jakob Unterwurzacher wrote:
> For me (Intrepid+proposed), this does not fix the issue.
> Suspend to ram -> resume gives me an APM level of 128.

This problem is known, confirmed and being worked on.
The bug is still open on pm-utils for this reason.
Don't bother to install any hacks, there will be an official fix soon.

Revision history for this message
Ralph Corderoy (ralph-inputplus) wrote :

I've acpi-support 0.109-0hardy2. There's one remaining issue that I'll point out in case others come searching. One of my drives has a -B of 64 by default. This is from `hdparm -I' having gone from power-up to single-user mode.

In the past, I'd altered /etc/hdparm.conf to have `spindown_time = 60', IOW `hdparm -S', for the drive and that gets applied on a normal boot. It was working; the drive would spindown after five minutes of idleness.

Now, the drive's -B is being set, for the first time, to -B 254 on booting. As this is over 127, my drive never spins down from idleness. Nor will it `spin down now, dammit' with `hdparm -y'. (I'm working around it with -B 127 after booting has finished.)

I don't know what the solution is, having not read through all the comments to see the underlying problem that's trying to be solved, but perhaps the drive's existing -B setting needs examining as part of determining the new value, i.e. don't mess with the top-bit.

Revision history for this message
Jakob Unterwurzacher (jakobunt) wrote :

What if you set "apm = 64" in hdparm.conf? Is it overwritten with 254 by the acpi-support script? Please file a new bug then, this one is already far too long...
If setting the apm level in hdparm.conf works it's not a real problem IMO as users need to edit hdparm.conf anyway to get the spindown. Caring about the old apm value isn't really possible as it varies wildy among drives, while meaning wildly different things.

Revision history for this message
Ralph Corderoy (ralph-inputplus) wrote :

> What if you set "apm = 64" in hdparm.conf? Is it overwritten with 254
> by the acpi-support script? Please file a new bug then, this one is
> already far too long...

I don't know. Due to bug #222458 I manually process /etc/hdparm.conf
a second time after booting has finished.

    awk '$1 ~ /^\/dev\/disk\// && $2 == "{" && NF == 2 { print $1 }' \
        /etc/hdparm.conf |
    while read d; do
        sudo env DEVNAME=$d /lib/udev/hdparm
    done

> If setting the apm level in hdparm.conf works it's not a real problem
> IMO as users need to edit hdparm.conf anyway to get the spindown.

Don't forget the user that, like me, added the spindown at least in
April 2008, if not before. A few days ago, his drive stopped spinning
down because of acpi-support's changes. It's not obvious to him to
think he needs to further modify the year-old /etc/hdparm.conf. Instead
he has to investigate and hopefully, like me, find this bug. As I said
earlier, that's one reason I'm describing the problem.

As I see it, the released fix can stop some drives spinning down that
were correctly configured before.

Revision history for this message
®om (rom1v) wrote :

The bug is mostly resolved, but there is still the problem sometimes when I let the laptop alone on battery (without doing anything). This morning I had the cycle count incremented by 30 in 2 minutes, and yesterday about 400 in (??? I don't know, but not a very long time).

Revision history for this message
Jakob Unterwurzacher (jakobunt) wrote :

@Ralph:
The hdparm.conf settings are overwritten by acpi-support's 90-hdparm.sh - i filed bug #318980 for this.

Revision history for this message
Cyberlion (rodrigoleao) wrote :

The bug solved, but the problem with the battery use is critical. And the HD is working in high temperature.

Revision history for this message
Steve Langasek (vorlon) wrote : Re: [Bug 59695] Re: High frequency of load/unload cycles on some hard disks may shorten lifetime

On Tue, Jan 20, 2009 at 01:05:20AM -0000, Cyberlion wrote:
> The bug solved, but the problem with the battery use is critical. And
> the HD is working in high temperature.

There is nothing in this change that should cause battery use to increase.
I think you should file a new bug report providing more details.

Revision history for this message
®om (rom1v) wrote :

I had the Cycle Count increased by more than 800 since yesterday.

I reapply this "fix" :
cmd='hdparm -B 254 /dev/sda';sudo $cmd && echo -e '#!/bin/sh\n'"$cmd" > /tmp/hdfix && sudo install /tmp/hdfix /etc/pm/power.d/00-hdparm.sh && sudo install /tmp/hdfix /etc/pm/sleep.d/00-hdparm.sh

to avoid the problem.

Revision history for this message
enubuntu (enubuntu) wrote :

the bug it's not solve!
i have increment of cycle when my laptop work with battery
please solve!
thanks

Revision history for this message
Steve Langasek (vorlon) wrote :

enubuntu,

It is intented that the hard drive be parked when running on battery, there's a trade-off between hard drive longevity and power usage. We do not consider this a bug and no fix is intended.

Revision history for this message
®om (rom1v) wrote :

Steve Langasek, ok the hard drive can be parked when running on battery, but sometimes it is too much (particularly when you do nothing, you let the computer alone on battery).

Last time, it parked about 400~500 times in 1 hour.

That's why I reapplied the "fix" which always set hdparm to 254.

Revision history for this message
Paul Sladen (sladen) wrote : Re: [Bug 59695] Re: High frequency of load/unload cycles on some hard disks may shorten lifetime

On Sat, 24 Jan 2009, ®om wrote:
> Last time, it parked about 400~500 times in 1 hour.

That would be once every 7-9 seconds. Is it even parking spinning down that
qiuckly?

Revision history for this message
Tobias Stegmann (punischdude) wrote :

Using the fix/updated acpi-support, my hdd gets very hot while idling. hddtemp says:

$ sudo hddtemp /dev/sda
/dev/sda: TOSHIBA MK1637GSX: 55°C

which is its maximum operating temperature. I don't want to think about what could happen if I make this drive doing sth.

Revision history for this message
unggnu (unggnu) wrote :

Maybe it is/was better to poll the hard drive on effected systen every x seconds to prevent spinning down but still let use the ohter features of apm.
Maybe the hardware vendors/ hard driver producers should be contacted how they deal with it under Windows.

Revision history for this message
Dennis Heinson (dheinson) wrote :

Not solved for me either. Noticed by loud clicks. Laptop mode disabled. Seems to only appear once I suspend the computer and bring it back from suspend. Load cycle counter increase of about 60 in 15 minutes.

Revision history for this message
Vincenzo Ciancia (vincenzo-ml) wrote :

Would it be possible for some influential ubuntu developer to talk to manufacturer and ask what policy would they use on their drives? It seems to me that there are too many unsolved problems and this bug is the second most commented bug on launchpad.

Revision history for this message
SirLancelot (lukaszgraczyk) wrote : Re: [Bug 59695] Re: High frequency of load/unload cycles on some hard disks may shorten lifetime

Hi,

This problem really exist on Ubuntu 8.10 and it's even worse than earlier
because some packages was updated to fix this problem, some system files
works different than earlier to fix this problem and effect of this "fixes"
is that people simly couldn't solve clicking their hard drives because
scripts, ugly fixes and all simple methods not working with updated files of
Ubuntu 8.10.

People from Ubuntu could say: "So why people still edit those files if it's
no effect with this problem". Because most of people tried to make it so
easy as You discribed in:

https://wiki.ubuntu.com/PowerManagement

And still hear hard disk clicking. What schould They do? Install Windows to
stop it or what? Instruction from PowerManagement link is:
ENABLE_LAPTOP_MODE=true" in /etc/default/acpi-support and it's simply not
working.

This problem exists so long. There was so many ugly and simle fixes that
could stop clicking but now non of them works because Canonical updates
files to solve this problem and updates could not solve this problem and
updates disabled almost every simle mathods to stop problem manually.

Many new people hear recomendation of Ubuntu from other users. Finally
install this system and one of first subject on every Ubuntu forums is "How
to stop Ubuntu to kill your hard drive". For me is very bad recomendation.

Could someone give me a link to original and clear:

/etc/laptop-mode/laptop-mode.conf

Because aftes so many solutions I'm not sure about what is clear Ubuntu 8.10
configuration in this file.

Thanks.

--

Pozdrawiam Serdecznie.

Łukasz Graczyk

Revision history for this message
Isaac Dupree (idupree) wrote :

Steve Langasek: sure, there's a tradeoff... but with sufficient knowledge, perhaps we could make it less bad. Suppose the hard-drive is specced to 600000 load-cycles. With smartctl we can measure the current number of load-cycles. Suppose there have already been 700000 load-cycles: wouldn't you think it'd be pushing your luck to park the head frequently, even if it saves power in the short run? More seriously, suppose you decrease or stop that behavior earlier, say at 500000 or 300000 load-cycles: so an older drive will use more power on battery, but at least Linux would then obey the principle of "do no harm". (If the hard-drive dies, the user has to replace it; if the hard-drive is just inefficient, the user still has the choice of replacing it, and is also less likely to lose data.)

Now we can look at something desired like "There should be fewer than ~15 load cycles per hour, except during heavy usage while on battery." that makes new drives last at least four years... if we adjust that number "15" in proportion to the actual (spec - load_cycle_count), then we'll manage to keep the drive pretty much safe from this kind of wearing-out!

however!

- we may not know the spec (is it bad to assume that it's 600000)?

- hard drives seem to be quite uncooperative: there might not be *any* good way to tell one "don't park any more often than X times an hour", even though there's a darned simple algorithm (disk remembers the last time it parked the head, and refuses to park the head again for the next 1/X hours). But maybe there's a way we can ensure that (frequent hdparm -B to different values? Is doing that likely to wear out the drive in any odd way?)

Revision history for this message
Michał Gołębiowski-Owczarek (mgol) wrote :

@ Łukasz Graczyk:
I attach unmodified version of my Intrepid /etc/laptop-mode/laptop-mode.conf.

Revision history for this message
SirLancelot (lukaszgraczyk) wrote :

Thanks Michał.

For this moment only issue that really works for me in 8.10 is:

1/ sudo gedit /etc/default/acpi-support
ENABLE_LAPTOP_MODE=true

2/ sudo gedit /etc/laptop-mode/laptop-mode.conf
http://wklej.org/id/44454/

Every other issues for me don't stop clicking even on AC.

--

Pozdrawiam Serdecznie.

Łukasz Graczyk

Revision history for this message
Steve Langasek (vorlon) wrote : Re: [Bug 59695] Re: High frequency of load/unload cycles on some hard disks may shorten lifetime

On Sun, Jan 25, 2009 at 06:13:26PM -0000, Isaac Dupree wrote:
> - hard drives seem to be quite uncooperative: there might not be *any*
> good way to tell one "don't park any more often than X times an hour",

In fact there isn't. Parking is handled by the drive itself according to
the APM power management settings; we don't really have a good interface to
control parking more finely than that. The only other approach to reducing
the number of load cycles would be to reduce the frequency with which Ubuntu
requires *un*parking the drive; that's worth investigating, but is going to
take a while to get to the bottom of and is probably not something we would
change in existing releases via SRU unless the fixes were obvious and
straightforward.

--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer http://www.debian.org/
<email address hidden> <email address hidden>

Revision history for this message
Adam Porter (alphapapa) wrote : Re: [Bug 59695] Re: High frequency of load/unload cycles on some hard disks may shorten lifetime

May I suggest that anyone who still has issues and comments on this
bug should include this information:

Laptop make and model
BIOS version
Hard disk make, model, and firmware revision (available from smartctl)

Perhaps we can discover a pattern of manufacturers or models which
handle certain settings in different ways.

Revision history for this message
Paganini (nebanks) wrote :

Hi Adam,

That seems like a good idea to me. I have this problem on two thinkpads, a 600E and an X40.

I gave the 600E to my sister a while back and it now runs XP, but it still has the clicking problem. It has a Hitachi drive similar to the one in my X40, but I don't recall the exact number.

The X40 has a Hitachi HTC426040G9AT00 with firmware 00P4A0L2. The BIOS version of my X40 is 1.22 (1UET74WW)

Revision history for this message
Dennis Heinson (dheinson) wrote :

The Thinkpad X40 uses 1.8" hard drives that have clicking (and failing) issues all of themselves. Your issues are probably unrelated to the bug at hand.

I am getting this issue with my new X200s Thinkpad using stock BIOS. It has a Seagate SATA ST91660827AS hard drive, firmware version: 3.CMF. The problem appears only after suspend/wake up on AC and battery.

Laptop-mode=disabled.

Steve Langasek (vorlon)
Changed in acpi-support:
assignee: ubuntu-kernel-acpi → vorlon
Revision history for this message
Steve Langasek (vorlon) wrote :

doesn't appear to be anything actionable here on linux/linux-meta, marking these tasks 'invalid'.

Changed in linux-meta:
status: New → Invalid
status: New → Invalid
status: New → Invalid
Revision history for this message
unggnu (unggnu) wrote :

Reducing the frequency of unparking is nearly impossible in Ubuntu, at least for the developers atm.
It isn't enough to higher the DIRTY_RATIO like laptop-mode does or exit or disabling hal-polling. If apps like Firefox are used they poll very often.
I personally got longer sleep times (nearly a minute) after doing the mentioned and moving /tmp and the firefox profile, macromedia and java directory to tmpfs. The problem is that the directories have to be synced to disk before shutdown and there are several more apps that poll recently I guess.

I still think it is the best to poll affected hard drives (high SMART parking values) recently and don't change the apm value. Of course this only makes sense if the hard drives doesn't get as hot with polling as with disabled apm.

At least for laptops the problem might be gone soon when SSDs are used more recently so just waiting might solve the issue too ;) .

Revision history for this message
Milan Bouchet-Valat (nalimilan) wrote :

Wouldn't it be the task of DeviceKit-disks to check for the drive's health and disable parking when it's happening too often or when the disk is near its end of life? I know it already does some SMART checks, so it could be easy to add this feature, and IMHO it's the place where things like that should be done.

Changed in acpi-support:
status: New → Fix Released
Changed in dell:
status: Confirmed → Fix Released
Revision history for this message
SirLancelot (lukaszgraczyk) wrote :

After latest acpi-support update bug looks like fixed on my 8.10 but with
one exception. When I close my laptop screen disk start to load/unload
cycles again.

Is it a rule on laptop hard disk with closed screen? Is it Your idea to make
something like protection of moving laptop with closed screen or wrong
working of the fix?

--
> High frequency of load/unload cycles on some hard disks may shorten
> lifetime
> https://bugs.launchpad.net/bugs/59695
> You received this bug notification because you are a direct subscriber
> of the bug.
>

--

Pozdrawiam Serdecznie.

Łukasz Graczyk

Revision history for this message
Bart Samwel (bart-samwel) wrote : Re: [Bug 59695] Re: High frequency of load/unload cycles on some hard disks may shorten lifetime

SirLancelot wrote:
> After latest acpi-support update bug looks like fixed on my 8.10 but with
> one exception. When I close my laptop screen disk start to load/unload
> cycles again.
>
> Is it a rule on laptop hard disk with closed screen? Is it Your idea to make
> something like protection of moving laptop with closed screen or wrong
> working of the fix?

The following scenario might cause this: (a) you have
CONTROL_HD_POWERMGMT=1 in laptop-mode.conf, and (b) you have
ENABLE_LAPTOP_MODE_WHEN_LID_CLOSED=1 in laptop-mode.conf. It might be
something else though!

Cheers,
Bart

Revision history for this message
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package acpi-support - 0.116

---------------
acpi-support (0.116) jaunty; urgency=low

  [ Jakob Unterwurzacher ]
  * Defensive quoting in 90-hdparm.sh, so that the script doesn't throw
    a syntax error when the battery state is undetermined.

  [ Steve Langasek ]
  * lib/power-funcs: refactor getState() to return 'AC' by default,
    since this is implicitly the case if we don't have a battery.
    LP: #59695.

 -- Steve Langasek <email address hidden> Fri, 30 Jan 2009 02:07:48 -0800

Changed in acpi-support:
status: Triaged → Fix Released
Revision history for this message
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package pm-utils - 1.2.2.4-0ubuntu2

---------------
pm-utils (1.2.2.4-0ubuntu2) jaunty; urgency=low

  * debian/95hdparm-apm: apply a default apm policy to all drives on
    resume/thaw, based on AC state, for consistency with the settings
    applied by acpi-support. LP: #59695.

  [ James Westby ]
  * debian/rules: don't install sleep.d/90clock, the kernel now handles
    setting the system clock on its own (and much more efficiently)
    without needing to call hwclock. Cf.
    <https://wiki.ubuntu.com/HardwareClock>. LP: #326183.

 -- Steve Langasek <email address hidden> Mon, 09 Feb 2009 17:07:28 +0000

Changed in pm-utils:
status: New → Fix Released
Revision history for this message
Steve Langasek (vorlon) wrote :

pm-utils uploaded to hardy/intrepid. Martin, please review at your convenience.

Steve Langasek (vorlon)
Changed in pm-utils:
status: Triaged → In Progress
assignee: nobody → vorlon
importance: Undecided → Critical
status: New → In Progress
Revision history for this message
Nicolò Chieffo (yelo3) wrote :

I'm on acpi-support 0.119 and pm-utils 1.2.2.4-0ubuntu2

When I'm on battery I hear very frequently the spin down noise. I bought my new laptop 1 month ago and the load cycle is 5180. Do you think I suffer this bug?

Now I set up /etc/laptop-mode/laptop-mode.conf using ENABLE_LAPTOP_MODE_ON_BATTERY=0 (it was 1 before)

I have a question to ask: how can I see the -B value of my disk with hdparm? I only know how to set it, but not how to get the current value.

Thanks for the informations

Revision history for this message
Bart Samwel (bart-samwel) wrote :

Nicolò Chieffo wrote:
> I'm on acpi-support 0.119 and pm-utils 1.2.2.4-0ubuntu2
>
> When I'm on battery I hear very frequently the spin down noise. I bought
> my new laptop 1 month ago and the load cycle is 5180. Do you think I
> suffer this bug?

Probably. But 5180 in one month is fine: that's about 60000 per year.
Your disk will last about 10 years at this rate.

Cheers,
Bart

Revision history for this message
Nicolò Chieffo (yelo3) wrote : Re: [Bug 59695] Re: High frequency of load/unload cycles on some hard disks may shorten lifetime

Thanks for the information. Anyway I noticed that leaving for 15
minutes my laptop on battery (with 128 as -B configuration), the
Load_Cycle raised of 15 (more or less). So I get one load cycle a
minute (fortunately only on battery). Is this the same case of you?
Why is my disk woken up once a minute during inactivity? kMaybe we
should also loo at this things

Thanks

Revision history for this message
Bart Samwel (bart-samwel) wrote : Re: [Bug 59695] Re: High frequency of load/unload cycles on some hard disks may shorten lifetime

Hi Nicolò,

Nicolò Chieffo wrote:
> Thanks for the information. Anyway I noticed that leaving for 15
> minutes my laptop on battery (with 128 as -B configuration), the
> Load_Cycle raised of 15 (more or less). So I get one load cycle a
> minute (fortunately only on battery). Is this the same case of you?
> Why is my disk woken up once a minute during inactivity? kMaybe we
> should also loo at this things

This is by design. On battery the load cycle does increase, because it
is useful to allow disk power management: for power saving, and to
protect against falling. It's been calculated that even for pretty
extremely mobile usage, your disk should be fine for a very long time.
On AC your load cycle should not increase (much).

Cheers,
Bart

Revision history for this message
Nicolò Chieffo (yelo3) wrote : Re: [Bug 59695] Re: High frequency of load/unload cycles on some hard disks may shorten lifetime

It's ok for me that my disk saves power while on battery, but I cannot
understand why once the read head is unloaded, every minute it is
loaded again. If the PC is idle who is causing the load cycle?
There might be a process that every minute accesses the disk, which is
not ok (in my opinion)

Revision history for this message
Bart Samwel (bart-samwel) wrote :

Nicolò Chieffo wrote:
> It's ok for me that my disk saves power while on battery, but I cannot
> understand why once the read head is unloaded, every minute it is
> loaded again. If the PC is idle who is causing the load cycle?
> There might be a process that every minute accesses the disk, which is
> not ok (in my opinion)

Fact of life, unfortunately. It's hard to fix all software -- there's a
lot of software out there. :-/

Cheers,
Bart

Revision history for this message
Yung-Chin Oei (yungchin) wrote :

On Fri, Feb 13, 2009 at 1:20 PM, Nicolò Chieffo <email address hidden> wrote:
> It's ok for me that my disk saves power while on battery, but I cannot
> understand why once the read head is unloaded, every minute it is
> loaded again. If the PC is idle who is causing the load cycle?
> There might be a process that every minute accesses the disk, which is
> not ok (in my opinion)

Nicolò: this is not really related to the bug discussion...
You might want to check out lm-profiler. Look at Bart's pages for a
description: http://www.samwel.tk/laptop_mode/faq

Revision history for this message
Nicolò Chieffo (yelo3) wrote :

That's right, sorry. Yung-Chin thanks for the page. I will try to find
out which is the process that accesses the disk.
Bye

Revision history for this message
Martin Pitt (pitti) wrote :

Accepted pm-utils into hardy-proposed; please test and give feedback here. Please see https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Thank you in advance!

Changed in pm-utils:
status: In Progress → Fix Committed
status: In Progress → Fix Committed
Revision history for this message
Martin Pitt (pitti) wrote :

Accepted pm-utils into intrepid-proposed; please test and give feedback here. Please see https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Thank you in advance!

Revision history for this message
Lorenzo Bettini (bettini) wrote :

I've just installed a brand new kubuntu 8.04 on a Dell Latitude D630; after the first boot I did an upgrade (without upgrading to 8.10 though), and the clicking problem is NOT there, load cycle NEVER increased in hours...

However, laptop mode is not enabled, so this was fixed somewhere else?

Revision history for this message
Babyshamble (babyshamble) wrote : Re: [Bug 59695] Re: High frequency of load/unload cycles on some hard disks may shorten lifetime

An educated guess: No, what happened is that your laptop's HDD wasn't
affected by the bug?

Revision history for this message
Lorenzo Bettini (bettini) wrote :

ehm... I gave it for granted: my laptop's HDD is affected by this bug, in fact, in previous versions of kubuntu I was using the ugly fix. (I started with 7.04 and then upgraded the system up to 8.04.)

Then today, I decided to install 8.04 from scratch and the bug is not there anymore (of course, I haven't reapplied the ugly fix, so the packages now seem to work fine).

Laptop mode starts automatically on battery.

On battery the cycle counts is more than 100 per hour, is this reasonable?

However, I confirm: no click on AC!

Revision history for this message
Steve Langasek (vorlon) wrote : Re: [Bug 59695] Re: High frequency of load/unload cycles on some hard disks may shorten lifetime

On Sat, Feb 21, 2009 at 04:52:42PM -0000, Lorenzo Bettini wrote:

> On battery the cycle counts is more than 100 per hour, is this
> reasonable?

Is it reasonable: no, but I don't think we can fix the problem of frequent
un-parking from any of the power management packages.

--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer http://www.debian.org/
<email address hidden> <email address hidden>

Revision history for this message
Dennis Heinson (dheinson) wrote :

This bug is far from being fixed. I am using the latest -proposed packages in intrepid. Same behavior for me as for other reporters: When I boot up on AC power -> no problems.

When I go to battery, the issue appears and will STAY even when I reconnect AC power. I get around 10 load/unload cycles per MINUTE. It will only go away after a reboot. This happens regardless LAPTOP_MODE=enabled or =disabled.

I am using a Thinkpad X200s with a Seagate ST9160827AS hard drive.

Please remove the "fix released" tags - this issue is NOT fixed. Plus, if I may add, I find it silly to claim that this cannot be fixed entirely because "the hardware sucks". This issue doesn't appear in other operating systems so there must be a way to make it work.

Revision history for this message
Nicolò Chieffo (yelo3) wrote : Re: [Bug 59695] Re: High frequency of load/unload cycles on some hard disks may shorten lifetime

Well. I think that hdparm -B 128 is a too low value... This is the problem!

I've set it to 200 and now I don't have an infinite number of head
parking as before!

you have to edit the files named 90-hdparm.sh in the directories and
replace 128 with 200
/etc/acpi/ac.d/
/etc/acpi/start.d/
/etc/acpi/battery.d/
/etc/acpi/resume.d/
Then insert and remove the AC adapter and wait to see if the head
parks a lot again

(I really don't understand why there are 4 duplicate files... They
could be symlinks...)

Revision history for this message
Matteo Collina (matteo-collina) wrote :

I really don't understand why there are still these kind of files under /etc/acpi while there is the the new infrastructure under /usr/lib/pm-utils/. These kind of problems should be adressed only in one place to keep the solution simple and maintainable.

Revision history for this message
Steve Langasek (vorlon) wrote : Re: [Bug 59695] Re: High frequency of load/unload cycles on some hard disks may shorten lifetime

On Sun, Feb 22, 2009 at 12:18:43PM -0000, Nicolò Chieffo wrote:
> Well. I think that hdparm -B 128 is a too low value... This is the
> problem!

> I've set it to 200 and now I don't have an infinite number of head
> parking as before!

Because setting it to 200 is defined to not permit spin-down. It is an
implementation decision to continue to spin down when on battery, not a bug.

--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer http://www.debian.org/
<email address hidden> <email address hidden>

Revision history for this message
Rocko (rockorequin) wrote :

This bug has very recently come back in Jaunty specifically when I resume without power attached and then attach the power cable. More importantly, issuing a sudo hdparm -B 254 doesn't fix it when it happens. I've opened bug #361680 for it since it seems to be otherwise fixed in Jaunty.

Changed in laptop-mode-tools (Mandriva):
status: Confirmed → Invalid
Revision history for this message
Xandros Pilosa (folivora) wrote :

Concerning pm-utils 0.99.2-3ubuntu10.1 from Hardy-proposed :
targeted behaviour achieved here.
Hdparm -B 128 on battery and hdparm -B 254 on AC, also persistent after resuming from STR or hibernation and switching from bat. to AC and back.
HP Pavilion tx1000
HD: FUJITSU MHY2120BH
Ubuntu Hardy 8.04.2
Sorry for late response and many thanks.
Regards!

Martin Pitt (pitti)
tags: added: verification-done
removed: verification-needed
Revision history for this message
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package pm-utils - 0.99.2-3ubuntu10.1

---------------
pm-utils (0.99.2-3ubuntu10.1) hardy-proposed; urgency=low

  * debian/95hdparm-apm: apply a default apm policy to all drives on
    resume/thaw, based on AC state, for consistency with the settings
    applied by acpi-support. LP: #59695.

 -- Steve Langasek <email address hidden> Mon, 09 Feb 2009 16:01:01 +0000

Changed in pm-utils (Ubuntu Hardy):
status: Fix Committed → Fix Released
Revision history for this message
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package pm-utils - 1.1.2.4-1ubuntu8.1

---------------
pm-utils (1.1.2.4-1ubuntu8.1) intrepid-proposed; urgency=low

  * debian/95hdparm-apm: apply a default apm policy to all drives on
    resume/thaw, based on AC state, for consistency with the settings
    applied by acpi-support. LP: #59695.

 -- Steve Langasek <email address hidden> Mon, 09 Feb 2009 16:01:01 +0000

Changed in pm-utils (Ubuntu Intrepid):
status: Fix Committed → Fix Released
Revision history for this message
ethanay (ethan-y-us) wrote :

If the intention is to enable a apm setting of 128 when on battery, where is the rationale and evidence explaining how
1. it actually protects the hdd from shocks
2. it actually saves power
3. evidence (even anecdotal) of drives overheating otherwise

my understanding and experience is that Ubuntu software polls the hdd too frequently and cancels out #1 and #2 above, because the hdd parks and unparks again almost immediately. thus, there is no real shock protection and no power saving (maybe even increased power consumption due to unnecessary activity?), and in the absence of any heating issues (not a problem on AC, by the way?), it makes no sense whatsoever to use an apm value of 128 until software can be written with the standard of reduced polling frequency while on battery mode.

cheers,
ethan

Revision history for this message
Marcin Kowalczyk (qrczakmk) wrote : Re: [Bug 59695] Re: High frequency of load/unload cycles on some hard disks may shorten lifetime

On Jun 7, 2009 10:00 PM, "ethanay" <email address hidden> wrote:

If the intention is to enable a apm setting of 128 when on battery, where is
the rationale and evidence explaining how
1. it actually protects the hdd from shocks
2. it actually saves power
3. evidence (even anecdotal) of drives overheating otherwise

my understanding and experience is that Ubuntu software polls the hdd
too frequently and cancels out #1 and #2 above, because the hdd parks
and unparks again almost immediately. thus, there is no real shock
protection and no power saving (maybe even increased power consumption
due to unnecessary activity?), and in the absence of any heating issues
(not a problem on AC, by the way?), it makes no sense whatsoever to use
an apm value of 128 until software can be written with the standard of
reduced polling frequency while on battery mode.

cheers,
ethan

-- High frequency of load/unload cycles on some hard disks may shorten
lifetime https://bugs.launc...

Revision history for this message
ktulu77 (ktulu-highwaytoacdc) wrote :

Hi.

I have a XPS M1530 and I have the strange HD clicks 1 or 2 times per minutes.

I am on ubuntu 9.04 x64. I don't understand why this bug is marked as fixed.

I don't understand what I have to do to fix this problem. The bug report is huge. What can I do to save my HDD and do not lost my data ?

Revision history for this message
houstonbofh (leesharp) wrote : Re: [Bug 59695] Re: High frequency of load/unload cycles on some hard disks may shorten lifetime

ktulu77 wrote:
> Hi.
>
> I have a XPS M1530 and I have the strange HD clicks 1 or 2 times per
> minutes.
>
> I am on ubuntu 9.04 x64. I don't understand why this bug is marked as
> fixed.
>
> I don't understand what I have to do to fix this problem. The bug report
> is huge. What can I do to save my HDD and do not lost my data ?

The answer is to enable laptop mode. However, you point is valid that
you have to know to do this! So, I agree that this bug should not be
marked as "Fixed" if there is no intuitive way to know how to save your
drive.

Revision history for this message
George A (georgeabraham-ro) wrote :

The bug still exists in any ubuntu (9.04/9.10, x86) and I'm using a desktop computer with two WD6401AALS drives. Every minute, or every few minutes, four clicks occur. This is annoying to say the least, and if it will go on, I will simply walk away from linux. I have tried every solution (enabling laptop mode, setting hdparm -B 254/255), but the bug still persists. And I'm using a DESKTOP computer. F*ck. This is not fixed, but plaguing high and low.
Please, I need a solution other than going back to windows!

Revision history for this message
taka k. (scar) wrote :

i have been living with this problem for years, never occurred to me it could be resolved through software. i have a sony vaio pcg-tr3a with hitachi HTC426040G9AT00 disk drive. i don't think it keeps track of the load cycle with a human readable number, but it is definitely increasing:

$ date; sudo smartctl -a /dev/sda|grep Load_Cycle_Count
Fri Jan 29 00:43:37 MST 2010
193 Load_Cycle_Count 0x0032 011 011 000 Old_age Always - 9055335103588
scar@kovu:~$ date; sudo smartctl -a /dev/sda|grep Load_Cycle_Count
Fri Jan 29 00:47:17 MST 2010
193 Load_Cycle_Count 0x0032 011 011 000 Old_age Always - 9055351880805
$ date; sudo smartctl -a /dev/sda|grep Load_Cycle_Count
Fri Jan 29 00:56:07 MST 2010
193 Load_Cycle_Count 0x0032 011 011 000 Old_age Always - 9055368658022
$ date; sudo smartctl -a /dev/sda|grep Load_Cycle_Count
Fri Jan 29 00:56:32 MST 2010
193 Load_Cycle_Count 0x0032 011 011 000 Old_age Always - 9055385435239

i am using ubuntu 9.04 with acpi-support 0.121, and i have enabled laptop mode in /etc/default/acpi-support

it doesn't seem to have helped, but i understand it is only supposed to help when on battery power?

this laptop remains stationary and on AC power, so i would like to also hear about a solution for this scenario.

ceg (ceg)
description: updated
Revision history for this message
Jimmy Merrild Krag (beruic) wrote :

Just installed lucid. Still got lots of load cycling, even though I've turned stopping the hard drive off. Any (hopefully) helpful information I can post?

Revision history for this message
Jimmy Merrild Krag (beruic) wrote :

Oh yeah. Running Lucid 64 bit.

Revision history for this message
Milan Bouchet-Valat (nalimilan) wrote :

Please don't open new tasks against random projects without explanation and actual reasons. Thanks!

Changed in acpi-support:
status: New → Invalid
Changed in laptop-mode-tools (Mandriva):
status: Invalid → Unknown
Changed in laptop-mode-tools (Mandriva):
importance: Unknown → Critical
Revision history for this message
Adam Porter (alphapapa) wrote :

I've been getting some of these LinkedIn spam invites lately, but how are they being sent to this bug's address? This is getting ridiculous.

Revision history for this message
Chow Loong Jin (hyperair) wrote : Re: [Bug 59695] Re: High frequency of load/unload cycles on some hard disks may shorten lifetime

On 05/05/2011 09:12, Adam Porter wrote:
> I've been getting some of these LinkedIn spam invites lately, but how
> are they being sent to this bug's address? This is getting ridiculous.
>

Probably from Gmail contact lists.

--
Kind regards,
Loong Jin

Revision history for this message
Grizzly (sven-witterstein) wrote :

Not sure if it's related or simply common knowledge - the WD EcoGreen "EARS" Advanced Format drives unter natty still park their heads every eight seconds.... smartctl in rc.local does lower the Load_Cycle_Count but does not fully help. There is a linux version of wdidle3 that also did not help much - so, there are still configurations after years with this problem...

Revision history for this message
theghost (theghost) wrote :

Same here on Ubuntu 11.04 Natty with a Western Digital Scorpio Blue. Every 7-8 seconds the load_cycle_count increases.

Additionally, ff I activate HDD spin down when running on battery in the power manager, I hear a clicking noise of my hdd every second. I can gurantee that this clicking sound is unsual, normally when parking the hdd's head. Deactivation of spin down setting helps, but load_cycle increases still every 7 seconds.

Based on this, it seems that there are still problems with the HDD management.

Revision history for this message
Andrzej Kłapeć (solidslash) wrote :

Unfortunately, the dirty fix of setting APM to 254 doesn't end this issue. My hard disk is WDC WD2500BEVT-75ZCT2 (Dell Studio 1555) and, on Ubuntu 11.04, it gets really hot on the default settings. (up to 50 C on idle and even 54 C when copy/pasting) The load_cycle_count doesn't seem to go up very fast though. Setting to, for example, 239 makes the temperature go lower but then the load_cycle_count increases like crazy. I mentioned the 239 value because I use it on Windows 7 by applying it by quietHDD and both the temperature and load_cycle_count problems are non-existent.
Isn't it affected anyhow by ext4 and how it uses the drive to read/write data? It seems to be using hdd all the time.

Revision history for this message
Adam Hallgat (hallgat) wrote :

Ocassionaly frequent load-unload cycles happens under Oneiric 11.10 Beta 1 usually when watching youtube.
This happened from 10.04 and up on every ubuntu distro. 10.04 clearly tried to kill my hard drive, fortunately the never versions are less cruel :) As I know there still isn't a 100% workaround for my hdd.

I'm using a NEC Versa one laptop without ( ACPI=off ) with the hdd below:

*-disk
                description: ATA Disk
                product: ST9120822AS
                vendor: Seagate
                physical id: 0.0.0
                bus info: scsi@2:0.0.0
                logical name: /dev/sda
                version: 3.AL
                serial: 5LZ7Z1VR
                size: 111GiB (120GB)
                capabilities: partitioned partitioned:dos
                configuration: ansiversion=5 signature=2bd2c32a

Revision history for this message
CLI (m-wichtowski) wrote :

I think the workaround for the problem is to install laptop-mode-tools and in /etc/laptop-mode/laptop-mode.conf change line:
BATT_HD_POWERMGMT=1
to
BATT_HD_POWERMGMT=254
This of course sets default disk APM to 254, but with laptop mode tools my WD Scorpio Blue 500GB stays pretty cool (about 43 degrees Celsius) and there is no idle drive "clicking" from now on. I've tested it on 11.04 and 10.04.
Maybe laptop-mode-tools should be installed by default on all laptops?

Revision history for this message
Adam Hallgat (hallgat) wrote :

I usually write hdparm -B 254 /dev/sda to the /etc/rc.local to set the APM 254 or 255, so if laptop-mode-tools only do the same unfortunately it won't be enough.

For example my harddrive is Seagate ST9120822AS. If you check https://wiki.ubuntu.com/DanielHahler/Bug59695
it shows there is no known safe APM setting exists to this hard drive. In the earlier Ubuntu distributions I tried both 254 and 255 but they didn't solve the problem for me.

For many hdd it shows solution but for mine and some others there isn't any known solution.

Revision history for this message
Yann (lostec) wrote :

6 Month ago I upgraded a previous 2.5" laptop internal WD Sata 320GB 5400rpm HDD for another WD (scorpio black?) 750GB 7200rpm:

cat /proc/scsi/scsi

labels it as:
WDC WD7500BPKT-0 Rev: 01.0

The 320GB one was responding to various "hdparm -B VALUE" values... with 254/255 shutting off spindown/unload completely...
The 750GB new one doesn't seems to care at all!

Ubuntu version unchanged (10.04), only disks copy (dd command with an USB adapter)/changed.

And unload seems more brutal and loud than previous device, maybe because of increased rpms.

For the moment, no problem with it... but the issue is probably with new HDD firmwares that does not take care of energy saving modes/values to exhibit good performance per watt figures in tests, whatever the test configuration/OS. Even if that may cause reliability problems.

Needless to say that booting windows partition does not change anything. That's not a linux problem.

Revision history for this message
Serhiy (xintx-ua) wrote :

It looks like WD BEVT-series was not mentioned here and the kernel.org is still down.
I just noticed huge Load_Cycle_Count on the WD1600BEVT-80A23T0. It almost reached 300 000 when I stopped it (299 252 to be precise) with
hdparm -B 255 /dev/sda
-B 254 didn't help, it just _ignored_ it.

Power_On_Hours is 2771 and that gives an average of 107 cycles per hour. Which is still very small compared to what I've heard today: it parks every 3-6 seconds (!) on the battery.

I didn't read all the comments (there is way too much of them) so if there was a better fix then disabling APM at all, please inform me.

FYI: it's an Asus T101MT notebook.

Revision history for this message
Andrzej Kłapeć (solidslash) wrote :

Guys, I don't want to jinx it but... about 5 hours ago I installed Ubuntu 12.04 alpha 2 on my laptop (WD2500BEVT hdd) and, without further configuring it (no changes to apm or anything like that) it WORKS. Just WORKS.
The temperature stays at 45'C and the load_cycle_count didn't increase even by one for these 5 hours! I'm shocked. I have no idea what's going on.
Now I'm moving to Ubuntu as my primary OS. Whoever contributed to this - thank you.

Revision history for this message
Brian Ealdwine (eode) wrote :

(!) really? ..wow.

Revision history for this message
Mikko Rantalainen (mira) wrote :

SolidSlash (solidslash): it might be that recent kernel tweaks for ACPI (and other power management) support may have triggered a fix for this issue. If that's true, any distribution with a recent enough linux kernel should be fine.

Revision history for this message
Joonas Saarinen (jza) wrote :

But the head parking is part of the normal drive operation. So why avoid it?

It's actually beneficial as it unloads the head, thus protecting the disk from shocks (and saving some power). Not a heavy operation like starting/stopping the disk.

Revision history for this message
Yves-Eric Martin (yem-launchpad-net) wrote :

@JoonasSaarinen

It is normal only if done not too frequently. Because otherwise, it can kill a drive. And that is not just theoretical, it can happen much more quickly than you may think: I had a drive with that issue, but very quiet so I did not notice. The result: the drive died in a catastrophic failure after only 5 months of operations (and over 800,000 Load_Cycle_Count!).

I don't think destroying itself in 5 months qualifies as "normal drive operations."

Revision history for this message
Santiago Roland (santiago-roland) wrote :

I gave to my wife a new Samsung N150 Plus Netbook last year. Last month the hard drive died but the warranty covered a new hard drive, so it was fine. Now with the new hard drive i was able to hear every 6 seconds that the heads are parking, and i tried many things and i cannot make it stop. Now i wonder the first hard drive (the one that died 1 months ago and my wife lost tons of data) died because of this bug. I know that this is an old bug now, but in this netbook is defenitly back and i tried adding this command in /etc/init.d

sudo hdparm -B 255 /dev/sda

even i tried to edit the laptop_mode.conf settings to do no power management in this hard drive and i had no luck, the packages had changed over the last versions of ubuntu and i do not know where to edit to disable this powr management. Now this hard drive has over 16000 load cycle counts and it keeps growing.

Anyone has starting to experience this? how do i stop this power management in order to save this drive because the netbook warranty just expired this month?

regards

Revision history for this message
Santiago Roland (santiago-roland) wrote :

I forgot to say that the version of ubuntu is 11.10 oneiric and the drive has 660 power on hours. he 6 seconds interval between parks is when using battery

Revision history for this message
In , Dimitrios (dimitrios-redhat-bugs) wrote :

Dear all, may I request that you reopen this bug?

On Fedora 17 I get the following on a 2 year used hdd:

# smartctl -A /dev/sda | grep ^193
193 Load_Cycle_Count 0x0012 064 064 000 Old_age Always - 366975

My hard disk is a Hitachi HTS545025B9A300, and as seen in the datasheet at [1] the expected lifetime is 600K load cycles. So I argue that this *is* a bug for Fedora, and the proper fix would be to "smartctl -B 254" when on AC and "smartctl -B 128" when on battery. I think that's the fix implemented in Debian/Ubuntu, see [2].

[1] http://www.hgst.com/tech/techlib.nsf/products/Travelstar_5K500.B
[2] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=448673

If you are interested I can come up with a patch, it seems pretty simple, as I think the proper place for running hdparm would be "/etc/pm/{power,sleep}.d/, at least to take care of the AC/battery switching. Can someone inform me if these directories are appropriately scanned and executed when systemd boots the system, or different hooks (where?) would be needed for that case?

Changed in somerville:
importance: Undecided → Low
status: New → Fix Released
no longer affects: dell
Revision history for this message
Timothy R. Chavez (timrchavez) wrote :

The bug task for the somerville project has been removed by an automated script. This bug has been cloned on that project and is available here: https://bugs.launchpad.net/bugs/1305705

no longer affects: somerville
Revision history for this message
Aaahh Ahh (woohoomoo2u) wrote :

Back at it in Ubuntu 15.10

Revision history for this message
Ryan Waldroop (ryan.waldroop) wrote :

Seriously? That's how many years? Come on!

On Thu, Aug 27, 2015 at 9:21 PM, Aaahh Ahh <email address hidden> wrote:

> Back at it in Ubuntu 15.10
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/59695
>
> Title:
> High frequency of load/unload cycles on some hard disks may shorten
> lifetime
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/acpi-support/+bug/59695/+subscriptions
>

Revision history for this message
Brian Ealdwine (eode) wrote :

Right? This is just sad.
On Aug 27, 2015 9:41 PM, "Ryan Waldroop" <email address hidden> wrote:

> Seriously? That's how many years? Come on!
>
> On Thu, Aug 27, 2015 at 9:21 PM, Aaahh Ahh <email address hidden>
> wrote:
>
> > Back at it in Ubuntu 15.10
> >
> > --
> > You received this bug notification because you are subscribed to the bug
> > report.
> > https://bugs.launchpad.net/bugs/59695
> >
> > Title:
> > High frequency of load/unload cycles on some hard disks may shorten
> > lifetime
> >
> > To manage notifications about this bug go to:
> > https://bugs.launchpad.net/acpi-support/+bug/59695/+subscriptions
> >
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/59695
>
> Title:
> High frequency of load/unload cycles on some hard disks may shorten
> lifetime
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/acpi-support/+bug/59695/+subscriptions
>

Revision history for this message
ethanay (ethan-y-us) wrote :
Revision history for this message
Nick B. (futurepilot) wrote :

What is your test case? Are you sure this is the same bug?

On Friday, August 28, 2015 01:21:14 AM Aaahh Ahh wrote:
> Back at it in Ubuntu 15.10

Revision history for this message
ethanay (ethan-y-us) wrote :
Download full text (9.5 KiB)

For me, it's that the OS leaves insane hardware mfr defaults of hdparm
-B=128 in place even on AC power. I believe this was fixed in 12.04 but is
back for some reason in 14.04 for me... Installing TLP changes to B=254 on
AC and retains the B=128 on battery (with the addition of clustering hdd
writes to help prevent excessive disk activity and thus load/unload
cycles), so provides essentially the same fix with added benefits of actual
power saving on battery

ethan

“A society grows great when its elders plant trees whose shade they know
they shall never sit in.” -- an ironic Greek proverb

On Sat, Aug 29, 2015 at 6:48 AM, Nick B. <email address hidden> wrote:

> What is your test case? Are you sure this is the same bug?
>
> On Friday, August 28, 2015 01:21:14 AM Aaahh Ahh wrote:
> > Back at it in Ubuntu 15.10
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/59695
>
> Title:
> High frequency of load/unload cycles on some hard disks may shorten
> lifetime
>
> Status in acpi-support:
> Invalid
> Status in acpi-support package in Ubuntu:
> Fix Released
> Status in linux-meta package in Ubuntu:
> Invalid
> Status in pm-utils package in Ubuntu:
> Fix Released
> Status in acpi-support source package in Hardy:
> Fix Released
> Status in linux-meta source package in Hardy:
> Invalid
> Status in pm-utils source package in Hardy:
> Fix Released
> Status in acpi-support source package in Intrepid:
> Fix Released
> Status in linux-meta source package in Intrepid:
> Invalid
> Status in pm-utils source package in Intrepid:
> Fix Released
> Status in acpi-support source package in Jaunty:
> Fix Released
> Status in linux-meta source package in Jaunty:
> Invalid
> Status in pm-utils source package in Jaunty:
> Fix Released
> Status in acpi-support package in Baltix:
> Fix Released
> Status in acpi-support package in Debian:
> Fix Released
> Status in pm-utils package in Fedora:
> Invalid
> Status in laptop-mode-tools package in Mandriva:
> Unknown
> Status in Suse:
> Fix Released
>
> Bug description:
> The kernel wiki gathers info about drives with too aggressive power
> saving defaults. A script called "storage-fixup" is also available.
>
> https://ata.wiki.kernel.org/index.php/Known_issues#Drives_which_perform_frequent_head_unloads_under_Linux
>
>
> This is not a support forum. Please do not use it as such (even though
> it has been used as such already).
>
> You can scan through the bug for links to the Ubuntu forums where
> many, many different questions have been asked, answered, and re-
> answered. The temporary workaround is just below.
>
> See https://wiki.ubuntu.com/PowerManagement for an overview about what
> is involved and for a remedy.
>
> SRU justification: current behavior may lead to premature disk failure
> in laptops due to excessive unnecessary drive parking. Fix will
> disable disk cycling by default when on AC power, by correcting an
> error in the hdparm logic of acpi-support.
>
> For jaunty, this issue is addressed in acpi-support 0.115.
>
> TEST CASE:
>
> 1. With acpi-support 0.109 (hardy) o...

Read more...

Changed in pm-utils (Fedora):
importance: Unknown → Medium
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Related questions

Remote bug watches

Bug watches keep track of this bug in other bug trackers.