Mon 26 Dec 2011 05:54:48 PM UTC, comment #9:
What I observe is that the daemon doesn't prevent the disk from going idle, except when asking the temperature on the TCP port 7634 (and probably when regularly logging to syslog).
The strange thing is that asking the temperature immediately wakes up the hard drive if it is in standby mode, but does not reset the idle time counter. So if you ask regularly for the temperature, it doesn't prevent the disk from going to standby, but it immediately wakes it up afterwards when temperature is asked.
I don't know what the -w --wake-up option does, but it should be the behavior with this option, not without as it is the case...
smartd has an option -n in conf file to prevent it from waking up the drive, and -C option of hdparm returns the powermode of the drive, so it should be possible to do something for hddtemp not wake up the drive (event if it cannot return a result).
|
Mon 25 Jan 2010 08:36:24 PM UTC, comment #8:
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)
|
Wed 18 Nov 2009 02:43:32 PM UTC, comment #7:
I am having the same problem using hddtemp version 0.3-beta15 on Slackware 13 / 2.6.29.6.
I have 3 different P-IDE drives: Samsung SP1604N, WDC WD5000AAKB-00H8A0 and WDC WD3200JB-00KFA0. They are not connected to an IDE on main board, but to a PCI0680 Ultra ATA-133 Host Controller.
Running hddtemp on a sleeping drive does not wake it - it results in "drive is sleeping".
Starting the hddtemp deamon does not wake the disks neither.
But when I start the deamon when the disk is spinning, or wake the disk when the deamin is running, then it will never go to sleep again - not untill I kill hddtemp.
|
Tue 07 Jul 2009 06:45:54 PM UTC, comment #6:
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
|
Fri 06 Feb 2009 04:34:39 PM UTC, comment #4:
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.
|
Thu 05 Apr 2007 01:52:37 AM UTC, comment #2:
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
|
Mon 26 Feb 2007 06:37:23 AM UTC, original submission:
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
|