Bug 338230

Raising severity to "Major", because this issue may shorten hardware life.

Additional info:

  - Fresh install of 10.3 exhibits the same problem

  - The power management level is reset after both a reboot and after suspend-to-ram

  - LWN article: http://lwn.net/Articles/257426/

I've got the same problem with openSUSE 10.3 for x86-64 on Dell Inspiron 9400 with a Hitachi HTS722020K9SA00 drive. Prior to the upgrade, openSUSE 10.2 for x86-64 did not exhibit the problem.

I'm seeing similar behavior of openSUSE 10.3 x86-64 on a Dell Precision M90.

With the default configuration, I'm seeing a Load_Cycle_Count / Power_On_Hours ratio of 30.8216 or nearly 31 load/unloads per minute. This laptop is usually used with the power adapter plugged in.

This means that the Seagate ST9160823AS drive according to the manufacturer specifications of somewhere around 600,000 load/unload cycles per drive lifetime, I can expect only 2.2 years of operational use of the drive. As this laptop is often on 24 hours per day, this is unacceptable. Because servers and desktops are implementing power management as well, this is going to impact all kinds of systems.

I imagine this is related to Linux swap behavior impacting the power management features of the drive. Since this laptop has 3,354,360 bytes of usable memory, perhaps we should look into increasing the "cost" of swapping pages out to disk on systems that are performing power management on their drives? Another thought would be to pre-cache the important libraries and keep them from getting flushed during normal use?

Another more radical option would be to disable swap unless memory becomes critically low, but I've found that disabling swap can impact system stability in certain cases.

I meant nearly 31 load/unloads per hour.

One other note, I'm using KDE with kpowersave. I think the defaults for disk power management were standby after 10 minutes, suspend after 20 minutes, power off after 30 minutes.

(In reply to comment #5 from David Bailey)
> One other note, I'm using KDE with kpowersave. I think the defaults for disk
> power management were standby after 10 minutes, suspend after 20 minutes, power
> off after 30 minutes.
> 

Nevermind. That's the screen, not drive.

My temporary hack for this issue, with a Hitachi HTS722020K9SA00, was to add the following line to /etc/init.d/boot.local:

hdparm -B 200 -M 128 -S 252 /dev/sda

This sets Advanced Power Management to 200, Automatic Acoustic Management to 128 (Quietest), and Standby/Spindown time to 21 min.

Due to the restructuring of the power management stack in the recent past, disk power management came off a little bit badly. We're working on that for the next openSUSE release.

Some kind of real fix, or a good workaround, would be to place a new hook into /etc/pm/power.d/

(some hints of doing this are at http://en.opensuse.org/Pm-utils#Creating_your_own_hooks)

It basically looks like this:

=============================
#!/bin/bash
. /usr/lib/pm-utils/functions

case "$1" in
        true)
                echo "**disabled pm harddisk"
                <some hdparm command> ;;
        false)
                echo "**enabled pm for harddisk"
                <some hdparm command> ;;
esac
============================


This can be called with 'pm-powersave {true,false}' and is also called by kpowersave or gnome-power-manager.

Maybe we should create a openSUSE wiki page with a suitable hook. Seife, what do you think?

Created attachment 184879 [details]
Two files for a work-around to power management issue on openSUSE 10.3

Here's a work-around encompassing two files:

/etc/sysconfig/pm-disk
/etc/pm/power.d/disk

/etc/sysconfig/pm-disk should be in /etc/pm/config.d/pm-disk. But that's only a minor addition. Thanks for the scripts! Maybe you can even create www.opensuse.org/DiskPowerManagement giving a short guide how to get this working? If not, nevermind, I will do it as soon time permits.

Yes, creating a wiki page sounds like a good short-term solution, i already created a feature request to solve this better in future releases.

Here's our work-around page. Please add to this if you can improve it.

http://en.opensuse.org/Disk_Power_Management

*** Bug 301691 has been marked as a duplicate of this bug. ***

What is the status of this bug? Is there going to be a fix? It's fairly major in my opinion.

i'll try to catch up with current upstream development of pm-utils and then reconsider the issue (maybe upstream already has a solution for it).

Would it make sense to mount all harddisks with the "realtime" flag? If not, would it at least make sense to add a checkbox to YaST's partitioning set-up that allows the user to add that flag via a GUI?

I meant relatime of course.

As written in Bug #386555, it's still present in 11.0 beta 2.

@Sven: I have a high load cycle count rate on 11.0 Beta2 even with "noatime,nodiratime".

I just submitted a package called "laptop-mode-tools" to the buildsystem (also available from my buildservice repository).

This package is integrated into pm-utils, so that the HAL "low power" method activates the "on battery" mode of laptop_mode, the "high power" method activates the "on AC" mode of laptop_mode.

Enable CONTROL_HD_POWERMGMT=1 in /etc/laptop-mode/laptop-mode.conf

BATT_HD_POWERMGMT=1
LM_AC_HD_POWERMGMT=254

Control the "hdparm -B" values sent to the disk.

More hints are in the duplicate bug 386555

*** This bug has been marked as a duplicate of bug 386555 ***

I just wanted to install your storage-fixup script from Bug 38655 today. So, thanks for providing the laptop mode tool! Activating it after install and configuring by "pm-powersave true", it seems to do the trick (on 10.3, I used a script based on the wiki about DPM). I will test it and post the results here and there.

"BATT_HD_POWERMGMT=1" will increase the already increased load cycle count rate up to 180 per hour for my system.

BTW, where should I file bugs and feature requests for ther new tool? 

Forget about my results. I just realized that there is a laptop mode init script.

- BATT_HD_POWERMGMT=1 in /etc/laptop-mode/laptop-mode.conf
- "chkconfig laptop-mode on" (make sure that laptop mode is started on every boot)
- "/etc/init.d/laptop-mode start" (or reboot)
- "pm-powersave true" -> powersave mode active, pretty aggressive unloading etc.
- "pm-powersave false" -> powersave mode disabled -> no unloading

The BATT_HD_POWERMGMT=1 is the "hdparm -B" value that is used for powersave mode, the LM_AC_HD_POWERMGMT=254 is the value for powersave-inactive mode.

I disabled the spindown with CONTROL_HD_IDLE_TIMEOUT=0 since a APM value of < 128 will spin down my disk no matter what idle timeout is given.

> I disabled the spindown with CONTROL_HD_IDLE_TIMEOUT=0 since a APM value of < 128 will spin down my disk no matter what idle timeout is given.

Yes, same here. I disabled it in my old 10.3 script, too. It was derived from 
http://en.opensuse.org/Disk_Power_Management

However, there seem to be a problem with some proc values:
# pm-powersave true
[...]
Adjusting 2.6 kernel parameters to enable laptop mode.
Executing: echo 2 > /proc/sys/vm/laptop_mode
Executing: echo 60000 > /proc/sys/vm/dirty_writeback_centisecs
Executing: echo 60000 > /proc/sys/vm/dirty_expire_centisecs
Executing: echo 60 > /proc/sys/vm/dirty_ratio
Executing: echo 1 > /proc/sys/vm/dirty_background_ratio
[...]
# /etc/init.d/laptop-mode status
[...]
/proc/sys/vm/laptop_mode:       2
/proc/sys/vm/dirty_ratio:       60
/proc/sys/vm/dirty_background_ratio:    1
/proc/sys/vm/dirty_expire_centisecs:    30
/proc/sys/vm/dirty_writeback_centisecs: 30

Something is resetting "dirty_expire_centisecs" and "dirty_writeback_centisecs".

pm-utils already contained a very crude and crappy laptop-mode script which is probably interfering here.

Make sure your pm-utils have this last changelog entry:

* Fr Mai 09 2008 seife@suse.de
- remove power.d/laptop-tools hook, is now handled much better by
  laptop-mode-tools package

If this is not yet available in FACTORY or you cannot update, then just remove the /usr/lib/pm-utils/power.d/laptop-tools file and try again. If it still does not work as expected, we have to further investigate ;-)

Okay. I removed the link and "dirty_expire_centisecs" and
"dirty_writeback_centisecs" keep their settings. Thanks!