This is what i found in the README of hddtemp:

"In daemon mode, hddtemp doesn't allow too much query at a time. If the interval between two query is inferior to 1 minute, ddtemp will give the previous value (hddtemp query the disk for each connection, if the period is superior to 1 minute)."

That means, if you want yout drive in standby mode you have to set your drives standby timeout below 1 minute.

Since 1 minute is relative short and the query interval is hardcoded, i created a patch which adds an optional command line option "-y seconds" or "--delay=seconds" to modify the fixed query interval.

I had the problem that collectd was querying the hddtemp daemon very 10 seconds, which didn't allow my drives to standby.

The patch is attached. If there is a skilled C programmer please review the patch.

I hope this project is not dead.

Best wishes,
Sebastian


(file #19548)

Encountering a similar problem on Gentoo.



I only recently noticed it so it is possible some other update (Kernel maybe?) recently triggered this.



The behaviour on my system is very strange however:

Drives that hddtemp is monitoring CAN spin down (e.g. with hdparm -y)



Drives that are excluded from hddtemp's monitoring CANNOT spin down!





It makes no sense!!! o.O

With my configuration (hddtemp 0.3-beta15-34 on Debian Etch) the problem does not seem to be the hddtemp daemon per se. If the disk is sleeping, neither 'hddtemp <disk>' nor 'hdparm -C <disk>' will spin it up. I.e., once I issue an 'hdparm -y <disk>' to spin down the disk, the hddtemp daemon does not spin up the disk again.

My guess is that the hddtemp daemon, collecting data for collectd at regular intervals, prevents the disk from falling asleep. It seems to interfere with the detection of the time the disk was not accessed.

I am sorry, I've failed with understanding your question. Perhaps the reply will be hidden in the following sentences.

What do I have: I am using three standard internal Seagate SATA-II. discs, connected into ICH8R drive controller. The controller is set (in BIOS) into (pseudo-)RAID mode, although no mirroring is happening currently. All of the discs seem to be working fine, they are correctly detected, and can be written and read. One of them bears boot data and whole file system.

How hdparm works: The discs correctly follow e.g. hdparm -Y or hdparm -I commands (i.e. they fall asleep, or they display the information). If a disk is in sleep mode, and it receives any of the mentioned commands, the prompt hangs for few seconds, then the disk starts to spin, and just after that the command is realised.

What breaks the sleep: If I avoid issuing hdparm commands pointing on sleeping disc, and I avoid accessing such a disc, the disc will remain sleeping forever. The only application so far, which used to wake any sleeping disks (within pretty short time), was the hddtemp.

What I have not tested yet: For an unknown reason, my Ubuntu box does not list "stand-by" mode in shut-down gnome menu. Also I cannot find, how could I setup the time of inactivity, after which the disc will automatically fall asleep. So the only way for now, how to send the disc into sleep mode, is the console command. The problem might be (and also might not be) in the fact, that my chipset is too new (Intel P965) for Unix world. I am not sure.

If the answer was not present among above lines, please be more explanatory, what should I test, and what aspect should I observe, and later describe.

Mike

With installed Hddtemp as daemon, my harddisk never goes idle even if there is absolute no activity.

If I try to force it (hdparm -Y /dev/sdb), the disk enters sleep mode immediatelly. However, with running hddtemp daemon, the disk returns back to ready state in a very short time.

I believe this is not the way how the application should work. Would it be possible to fix it?

This report applies at least to version 0.3-beta15, installed from official deb, running under Ubuntu Edgy x64 and latest stable kernel.

Mike