Laptops, power management, and Ubuntu

Conspicuous by its absence, so far, is any comment from drive manufacturers. It would be nice
to know...

• Did they know about this before it was widely reported ?
• Is there any hardware or firmware bug involved ?
• Do they consider the Load / Unload count to be a significant predictor of early drive
failure (most SMART old-age counters aren't very indicative of likely failure) ?
• Is the behavior (not just seen in Ubuntu) where these cycles occur very frequently actually
pathological, or was it considered an acceptable consequence for power saving ?
• Do they intend to alter the power on configuration of future drives in the light of these
results ?

Thanks for a great article! We really needed some objective, level-headed, fact-based
information about this. My 2-year old Ubuntu-from-birth laptop is affected (1.2 million
cycles), and the fixes mentioned in the thread didn't help. The linked wiki page is a sad
jumble of incomplete suggestions, as of this moment.

This article was the first place I have seen that explained that none of the fixes (hdparm)
would have any effect unless laptop mode was on. Other posts had led me to believe that I was
better off with laptop mode off.

I wish it had gone a little farther, though:

How can I tell if I am in laptop mode or not? First I had to find the laptop_mode FAQ page
(http://www.samwel.tk/laptop_mode/faq), which says "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." Ok, I'm
not in laptop mode.

How can I turn on laptop mode? It looks like the answer is in "man laptop-mode.conf".

Then there are several different suggestions (on that wiki page, in the launchpad thread, and
in various blogs) for how to ensure the spin-down settings persist across reboots, and in both
AC and Battery mode. How should one decide which method to use? Are some better than others?
Can I just change laptop-mode.conf can nothing else? Will all of approaches work on any
system? Should I just choose one at random?

Are there any distros that are *not* affected? If so, we might learn something from them. Are
there any "reasonable" changes that Ubuntu and others should make right away? Should they at
least notify users during install that further user action is required to avoid destroying
hardware?

Finally, how would one enable relatime? Since the lwn article in August, has there been more
research into what problems it might cause? This one probably deserves its own follow-up
article, since Fedora has decided to set it as the default.

The count on my two-month-old Thinkpad t60p is 600k+.  I am concerned.

My count on my Thinkpad X40 is 5662176519809 (sic). Given that the machine is around 3 years
old, if we assume it's been on all that time (which it hasn't) that indicates a head park
about 60,000 times a second. I knew these new hard disks were fast and the power-saving was
aggressive, but...

Seriously, anyone know why smartctl -A /dev/sda might give such an amazingly large figure?
I've just seen it increase by 16 million in 19 seconds, so something is rather wrong.

Gerv

For all the mandriva users out there, here's what seems to work for me (this is a Dell
something with a Hitachi 60 GB hard disk).  Note that I don't see why some eqvt of this won't
work for others too...

(1) make the following changes in /etc/laptop-mode/laptop-mode.conf.

    # 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.
    # Anything more than 10-15 minutes (900 seconds) ought to be OK, actually...
    LM_AC_HD_IDLE_TIMEOUT_SECONDS=5400
    LM_BATT_HD_IDLE_TIMEOUT_SECONDS=3600
    NOLM_HD_IDLE_TIMEOUT_SECONDS=7200

    # Should laptop mode tools control the hard drive power management settings?
    CONTROL_HD_POWERMGMT=1      # this has to be 1 else nothing happens, I believe

    # Power management for HD (hdparm -B values)
    BATT_HD_POWERMGMT=254       # 255 didn't work for me.
    LM_AC_HD_POWERMGMT=254
    NOLM_AC_HD_POWERMGMT=254

Notes on above:

I have found that controlling only "-B" is not enough.  As the original article said, in some
cases spindown also counts as a load/unload, so you need to fix "-S" also.

(2) in file /usr/share/pm-utils/sleep.d/92disk, added a line inside the function
"resume_disk":
        /sbin/hdparm -B 254 -S 241 /dev/sda

Notes on above:

(i) the code in the said file does not recognise SATA disks and I do not have the energy/time
(read: SMARTs, no pun intended!) to figure out how to make that happen, hence the hardcoding.
Please change the /dev/sda to whatever you have

(ii) if your hard disk is IDE, setting
        RESUME_DISK="-B 254 -S 241"
ought to be enough for you, but I have no way of testing that

(iii) why do I need to do this at all?  Glad you asked... ;-)

The reason is that the laptopmode hooks seem to kick in only when switching from battery to AC
or vice-versa.  When coming up from a suspend (whether to disk or to RAM), when there has been
NO change the AC/battery status, they DONT kick in, and you are left with the hard disk
default.  Which is what caused the problem in the first place!

This file (the /usr/share/pm-utils/sleep.d/92disk thing) *does* get called on a resume, so I
use that.

By the way this file is from the "pm-utils" package.

The question should probably be not who is to blame for it, rather what is the behaviour that
actually needs fixing.

Most articles on this topic seem to suggest that the issues is hard disk spinning down to
early (after a few tens seconds of inactivity), because the silly bios instructs them to do so
and the OS does nothing to change this default. Under this analysis the behaviour that needs
fixing is the hard disk power management level.

But a few voices tend to disagree. Maybe there is nothing wrong in hard disks spinning down
and parking early.  Maybe the hard disk and bios defaults are perfectly right in the vision of
a manufacturer that expects an OS not doing all that logging, all that writing down access
times, and the like.  Maybe, the problem is actually that the hard disk gets re-spinned up too
early even in complete absence of user activity.  Under this second analysis the behaviour
that needs fixing is the OS way of causing continuous hard disk writes, and not necessarily
the hard disk power management level.  It is to notice that this second analysis, in spite of
being minority, is supported by the fact that if one actually wants to get decent battery life
it is not the active-to-parked time to be enlarged, but the number of activations to be
reduced.

In my opinion, the first analysis is majority just because the problem it outlines is easier
to patch.  The second analysis actually says that the real issue is that the OS is not enough
aware of what a laptop is and of how to coordinate efforts to do power management. Namely, it
is silly to tell the hard disk to be aggressive, if the logging system does not defer logs,
etc.

If this is the case, a subsystem a la "laptop_mode", but enhanced is the real solution. When a
laptop is on battery _all_ the unnecessary hard disk activity should be very much deferred and
aggregated. This should include inner OS disk activity, logging, and applications (window
manager, GUI, etc). And this is something that is only partially possible to do now, because
logging daemons and applications cannot be easily switched between two different operating
modes.

Maybe, an OS that is truly ready for laptops should need one more signal than it has now.
There might be a signal to tell all processes that the system is changing power mode, so that
each change of status can be communicated to all processes. Legacy programs should just ignore
this signals. Laptop-aware programs should consider the change of status, read the new status
and cooperate with it.  BTW, this could be useful also to make applications aware of when a
system is going to suspend and take consequent actions (e.g. we might want a SIP client to
de-register before suspension and to re-register right after wake-up).

And one more thing: to do control proficiently, observing the achieved behaviour is often a
smart thing.  Since hard disks have "power levels" that are just "abstract", there should be
tools to keep accounting of spin-down and spin-up average times (either to be invoked one
shot, to determine best parameters for system and average use, or to be periodically in
operation).  This could also be used to alert the user if potentially dangerous hard-disk
behaviours should appear.