Comment 4 for bug 738757

I have done more testing with the patch released in hdparm (9.32-1ubuntu2) and found that there are some problems with the approach taken. I think this bug should be marked FIXED-FAILED and revisited.

By adding the hdparm -S parameter handling to the power.d script for 'true' and 'false' power.d events in addition to the 'thaw' and 'resume' events proposed in the original patch, a side effect has now been introduced. The drive will now be awakened from standby state for every power event transition ('true' and 'false') so that the hdparm -S command can be applied.

This is undesirable from several perspectives. First, and foremost, it wakes a sleeping drive to submit a command that affects how long the drive should wait before going to sleep. When the drive goes to sleep again, that parameter will be lost, so waking it to tell it that serves no positive purpose.

Unlike the -B apm parameter modification, the -S parameter should not be modified on both a 'true' and 'false' power event, since there is no side benefit to changing the -S parameter when entering or exiting powersave mode for a drive that is still awake, since it will already have the -S parameter from the hdparm.conf file currently applied. The -S parameter is static in the hdparm.conf file and should have been applied at power on, or when it last came back from standby or sleep on a 'resume' or 'thaw' event.

Another undesired consequence of applying the hdparm -S command in the power.d script is that it creates an incompatibility in the powernap utility with using the powersave ACTION mode in conjunction with the DiskMonitor plugin I have proposed https://code.launchpad.net/~jinfo/powernap/trunk. This is due to the fact that if the DiskMonitor is monitoring a drive to detect the standby/sleep state, and then subsequently tries to execute pm-powersave command, the drive will be awoken by the power.d script, which tries to apply the hdparm -S command to the drive that is in standby or sleeping, thus awakening it, and causing an invalidation of the conditions to enter low power mode (e.g. the drive is now awake).

Indeed, from my testing it seems as if even issuing a pm-suspend causes the 'true' condition of the power.d script to be triggered, as I am seeing sleeping drives awoken when I issue pm-suspend prior to the system going into standby. So the drives are awoken, given the new hdparm -S command and then the system enters standby where the drives are again immediately put back into standby, not good.

In my opinion, my original patch is the more correct handling of the loss of hdparm -S (spindown) settings within pm-utils. The reapplication of these settings should only be done from within the sleep.d script for 'resume' and 'thaw' events. Upon reawakening from sleep or standby are the only times the drive would have "lost" the settings contained in hdparm.conf.

Please reconsider using the original patch.

Best Regards,

-Jim Heck