[SOLVED] Debian 11 hdparm

[oqei]

Hi,

I set up a Debian 11 installation on my HC4 via petitboot's netboot_default. I'm trying to set the spindown time of my HDDs on boot, s.t. they automatically spin down. On a previous Ubuntu 20.04 installation this worked by writing configuring the settings in /etc/hdparm.conf. With the same file on Debian nothing happens. Looking into the config the syntax should still be the same, so I'm wondering what's the reason. If I understand it correctly, the config file should be read by a script that's triggered by udev, /usr/lib/pm-utils/power.d/95hdparm-apm. My best guess right now is that this doesn't happen on my system, for some reason. Is there something different on the HC4, the mainline kernel, ... compared to other systems that might cause udev to not be triggered?

I'm aware of workarounds I could use to achieve what I want to do with other means, still I'd like to understand the reason for the problem.

[tobetter]

Have you tried to set spindown time with hdparm command and does it work?

[oqei]

Yes, the command setting the time manually has the intended effect.

[tobetter]

Yes, the command setting the time manually has the intended effect.

Debian document does not introduce anything new if my understanding is correct.
Have you tried the command like DEVNAME=/dev/sda /lib/udev/hdparm so it force to read the config and spin down your storage?

[oqei]

I tried that, the HDDs don't spin down that way, either. To be sure I set the spindown time manually on sdb, which spun down after some time while sda remained active.

[tobetter]

I tried that, the HDDs don't spin down that way, either. To be sure I set the spindown time manually on sdb, which spun down after some time while sda remained active.

So...you mean /dev/sda cannot be spin down manually at all?

[oqei]

...

So...you mean /dev/sda cannot be spin down manually at all?

No, both disks spin down when manually setting the time via hdparm -S /dev/sdX, I was just trying both ways (manual & udev-triggered) in parallel on either disk to make that I was waiting for long enough since some vendors appear to have a custom logic on the spindown time.

[rooted]

If you are using any sort of drive temperature monitoring or anything accesses the drive or drive features it won't spin down.

[oqei]

If you are using any sort of drive temperature monitoring or anything accesses the drive or drive features it won't spin down.

To the best of my knowledge, there's nothing accessing the drives in any way. I believe I should have noticed that, since setting the time manually has the desired effect.

[rooted]

You could try blktrace to make sure nothing is accessing the drive

[oqei]

I don't think anything accessing the disk is at fault here. Currently the disk spins down reliably after accessing it for daily snapshots, but only after I set the spindown_time manually via hdparm. The only thing that's not working is having this trigger at boot via udev.

[oqei]

I believe I have narrowed down the source of the behavior. Long story short, there is a function to filter devices that is being operated on. In particular, this checks that a) the device is not attached via USB or Firewire, and b) that it supports APM. Neither condition is true in my case, so the configuration is not applied.

I believe that this behavior is a bit overzealous, since the first condition was introduced in reaction to a bug report from 12 years ago, so, since it works fine in my case I believe this filter is to broad, and the second one is that it's checked for APM (Advanced Power Management) capabilities, when for spindown-time regular PM is sufficient, which the device supports.

In any case, now that I understand the issue I'm happy to use one of the workarounds, just wanted to understand the behavior. Thanks alot for the help!