On Tue, May 15, 2012 at 08:20:42AM -0000, Neil Price wrote:
> I might be missing something, apologies if i am, but I notice that for
> Precise a decision was made to define a value for -S, in /lib/hdparm
> /hdparm-functions, when on battery to -S36. From Dagnachewl's comment
> (70) it would seem that it's the defining of or value of -S that's still
> causing issues for some.

It's incredibly unlikely that this is the cause of the problems some people
are still seeing.  It's more likely that the affected users simply have
problematic handling of -B128 - as Dagnachew's output in comment #55 shows,
-B128 gives him "Advanced power management level: 1".  I'm not sure if this
is in spec for the drives to do, but it's certainly unhelpful, and it seems
the *only* way to reliably prevent spin up/spin down nonsense on some drives
is to disable APM entirely with -B254.  Fixing this is out of scope for the
present bug report, which was about the behavior regression on non-"green"
drives caused by the move from -B128 to -B127.

So other issues are best addressed by separate bug reports.  We'll need to
gather a lot of information here before we dare making further changes - as
I said earlier, there's no magic setting that will work correctly across all
drives, so we need to be careful that as we tune things, we don't regress
behavior for other users (either in terms of power savings or in terms of
drive wear and tear).

In the meantime, users who find that -B128 causes their disks to spin down
too aggressively should probably just set apm_battery=254 in
/etc/hdparm.conf.

> For anyone who has already updated hdparm to version '9.37-ubuntu3.1'
> and still experiencing early spindowns I would try commenting out (by
> preceeding with #) or removing the line "hdparm_set_option -S36" from
> /lib/hdparm/hdparm-functions. This should effectively revert hdparm-
> functions to pre-Precise settings - removing any spindown time.

Since -S36 is a spindown time of 3 minutes, I don't think this setting is
related to the behavior users are seeing.  If it *is*, then those drives are
operating contrary to the spec and users should complain to their hardware
vendors and demand firmware updates.

> Steve: thanks for the update, works great for me! Maybe the wording of the
> change in the changelog needs updating.  Instead of '...drives are
> spinning back "up" so frequently' shouldn't it be '...drives are spinning
> "down" so soon'?

No, that wording is deliberate.  Ultimately, the real bug here is not that
we're spinning the drives down; the bug is that we're unable to *keep* them
spun down on a typical desktop.  There's no justification for having to hit
the disk any more frequently than once every 5-10 minutes on a default
install, and the fact that we do is a bug.  It might be a kernel bug, or an
application bug, or a filesystem bug - it's difficult to say categorically
because everyone's usage patterns seem to be different.  But ultimately, the
goal here should be to get better at our disk handling so that it doesn't
matter that we're spinning the disk down.

> It's that the drive has spun down after only a few seconds of idle (with
> -B127 and -S36) that leads to it having to spin back up so frequently.

If the drive is actually spinning down with -S36, rather than simply parking
the heads, that's a firmware bug anyway.

-- 
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>