OpenSuSE 12.3: How to make hdparm -S stick?

English Hardware
1

I’ve got all my music and video on a separate hard drive, so for the majority of the time when I’m not actually listening or watching anything I want it to spin down for reduced noise.

In SuSE 10.0 it was enough to write “hdparm -S 180 /dev/sdb” into /etc/init.d/boot.local. In OpenSuSE 12.3 that no longer works; the drive never spins down. I conclude that either (1) some process keeps accessing the drive at intervals shorter than a quarter-hour, or else (2) the -S setting is re-set by some distribution-provided process that I’m unaware of.

(1) seems less likely to me - the only system process I know that would spontaneously access an arbitrary, user-defined top-level directory is updatedb, and that runs only once per day. Also, it seems that when I run the hdparm command as root manually from a terminal, then the disk will eventually spin down.

Unfortunately, the -S option apparently can only be set, not queried, so I can’t be certain my problem is (2). But if it is, what subsystem/daemon/distribution service might be messing with my hdparm settings?

  • some power management service defined by SuSE?
  • I’m not running smartd, which is often named as a culprit for this.
  • I am running KDE, which I wasn’t before (I used OLVWM)
2

On 2014-06-01 16:26, vhpd wrote:

> In SuSE 10.0 it was enough to write “hdparm -S 180 /dev/sdb” into
> /etc/init.d/boot.local. In OpenSuSE 12.3 that no longer works; the drive
> never spins down. I conclude that either (1) some process keeps
> accessing the drive at intervals shorter than a quarter-hour, or else
> (2) the -S setting is re-set by some distribution-provided process that
> I’m unaware of.

In 13.1 the script runs, but I don’t remember about 12.3, there was some
version in which it did not.

So the first thing is finding out if it runs. If it does, then…
Well… you could try “after.local” instead, or “before.local”.

Otherwise… you could set up a cron job that sets it up again, just in
case.

> Unfortunately, the -S option apparently can only be set, not queried, so
> I can’t be certain my problem is (2). But if it is, what
> subsystem/daemon/distribution service might be messing with my hdparm
> settings?

Dunno.

> - some power management service defined by SuSE?
> - I’m not running smartd, which is often named as a culprit for this.
> - I -am- running KDE, which I wasn’t before (I used OLVWM)

laptop mode tools?

–
Cheers / Saludos,

Carlos E. R.
(from 13.1 x86_64 “Bottle” at Telcontar)

3

I’ve sorted by boot up problems out, and have confirmed that the setting *is *set correctly. But still the drive doesn’t go to sleep, and what’s more, if I send it to sleep explicitly with hdparm -Y, it wakes up again, sometimes after less than a minute. So my problem is (1) after all: some system process keeps reading from that disk!

But what process is is? I can never catch anyone holding an open file handle anywhere on the mounted directory via ‘lsof’, even if send the query before the drive has finished spinning up (i.e. when logically the disk access should still be unfinished). What system processes are there (other than updatedb) that keep reading every single available file on the entire system? How can I stop them from doing that?

4

Maybe a heart beat process

Did you try umounting it first??

5

On 2014-06-04 19:06, vhpd wrote:

> But what process is is? I can never catch anyone holding an open file
> handle anywhere on the mounted directory via ‘lsof’, even if send the
> query before the drive has finished spinning up (i.e. when logically the
> disk access should still be unfinished). What system processes are there
> (other than updatedb) that keep reading every single available file on
> the entire system? How can I stop them from doing that?

Use iotop. Install it from oss repo.

You will need some concoction to watch activity on that disk, or log all
activity to a file and grep it later.

Could be --batch and --only.

After the culprit is found, we can think something to stop it, if possible.

–
Cheers / Saludos,

Carlos E. R.
(from 13.1 x86_64 “Bottle” at Telcontar)

6

Thanks for pointing me to that great tool!

I now see that my problem is a combination of (1) and (2). If I set an
explicit timeout, the disk eventually spins down when I’m not watching
anything. And it stays asleep obediently until the daily cron job
starts. Then, of course, updatedb runs and wakes it up. But after
that, it no longer goes to sleep no matter how long I wait, even
though neither me nor the system is accessing it! Apparently,
something somewhere in SuSE’s daily cron tasks resets the hardware so
that the hdparm auto-sleep setting is forgotten. Case in point: if I
re-issue hdparm -S after the cron job has run, then the disk returns
to the desired behaviour: auto-sleeping after a quarter-hour if I’m
not watching stuff, keep spinning otherwise.

But I can find no occurrence of ‘hdparm’ in the cron job programs. The
only references that could conceivably be auto-run by somebody are two
obscure programs, /usr/sbin/wiper.sh (for SDD trimming) and
/usr/bin/xine-check. Is there anything else that might reset a disk
drive so hard that it forgets ATA settings? Should I try finding out
what is subverting my settings, or should I just try to get my hdparm
command into the very end of cron.daily?

7

On 2014-06-08 20:36, vhpd wrote:

> Thanks for pointing me to that great tool!

Welcome. Somebody told me about it, too :slight_smile:

> I now see that my problem is a combination of (1) and (2). If I set an
> explicit timeout, the disk eventually spins down when I’m not watching
> anything. And it stays asleep obediently until the daily cron job
> starts. Then, of course, updatedb runs and wakes it up. But after
> that, -it no longer goes to sleep no matter how long I wait-, even
> though neither me nor the system is accessing it! Apparently,
> something somewhere in SuSE’s daily cron tasks resets the hardware so
> that the hdparm auto-sleep setting is forgotten. Case in point: if I
> re-issue hdparm -S after the cron job has run, then the disk returns
> to the desired behaviour: auto-sleeping after a quarter-hour if I’m
> not watching stuff, keep spinning otherwise.

It is also possible that something else resets the sleep timeout much
earlier. When something (the cron job) accesses the disk, it does not go
to sleep.

I would try accessing that disk manually before the daily cronjob kicks
in, to find out if it is the culprit or not.

>
> But I can find no occurrence of ‘hdparm’ in the cron job programs. The
> only references that could conceivably be auto-run by somebody are two
> obscure programs, /usr/sbin/wiper.sh (for SDD trimming) and
> /usr/bin/xine-check.

xine-check? I doubt it.

> Is there anything else that might reset a disk
> drive so hard that it forgets ATA settings? Should I try finding out
> what is subverting my settings, or should I just try to get my hdparm
> command into the very end of cron.daily?

Possibly. If there is a service that writes disk defaults. There was one
such years ago, but it has disappeared, I could not find it.

I don’t know if systemd has something.

But… laptop mode tools would do it.

You could use them to set the no-sleep in there…

–
Cheers / Saludos,

Carlos E. R.
(from 13.1 x86_64 “Bottle” at Telcontar)