bugHddtemp - Bugs: bug #19150, Hddtemp daemon blocks harddisk...

 
 

bug #19150: Hddtemp daemon blocks harddisk from going idle

Submitter:  None
Submitted:  Mon 26 Feb 2007 06:37:23 AM UTC
Votes: 1
 
Category:  None Severity:  3 - Normal
Item Group:  None Status:  None
Privacy:  Public Assigned to:  None
Open/Closed:  Open
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

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).

Cyril Roussillon <cyril42e>
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)

Sebastian <sepo>
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.

Anonymous
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


Anonymous
Sat 04 Jul 2009 09:17:25 AM UTC, comment #5: 

Hi.

Same here with 0.3-beta15-45 on Ubuntu 9.04:

https://bugs.launchpad.net/ubuntu/+source/hddtemp/+bug/394892



Anonymous
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.

Anonymous
Sun 28 Dec 2008 03:33:09 PM UTC, comment #3: 

It's not really fixable, very few disks don't wake up when a S.M.A.R.T. command is sent to them. And AFAIK there is no way to determine whatever a drive is in sleep mode using standard ATA commands...

Anonymous
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

Anonymous
Sun 18 Mar 2007 06:17:53 PM UTC, comment #1: 

hddtemp should detect this. So either hddtemp is still buggy or you're drive is.
Do you get the same behaviour with hdparm when state informations ?

Emmanuel Varagnat <guzu>
Group administrator
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

Anonymous

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

Attached Files
file #19548:  daemon_query_delay.diff added by sepo (3KiB - application/octet-stream - Patch that adds a command line option "-y seconds" or "--delay=seconds" to change the query interval of the hddtemp daemon.)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by cyril42e (Voted in favor of this item)
  • -email is unavailable- added by cyril42e (Posted a comment)
  • -email is unavailable- added by sepo (Updated the item)
  • -email is unavailable- added by guzu (Posted a comment)
  •  

    There is 1 vote so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only logged-in users can vote.

     

    Follow 2 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2011-12-26 cyril42e Carbon-Copy- Added cyril42e
    2010-01-25 sepo Attached File- Added daemon_query_delay.diff, #19548

    Back to the top

    Powered by Savane 3.13-4448.
    Corresponding source code