Indicator-sensors wakes up idle drives

Bug #1377433 reported by Igor Tarasov
8
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Hardware Sensors Indicator
Fix Released
Medium
Alex Murray

Bug Description

The subject says it. I have indicator-sensors 0.7-0~233~ubuntu14.04.1 installed. Also, I have two drives (SSD/HDD). HDD unmounted, and once on battery it goes idle. If I add HDD sensor to be monitored, I keep hearing as my second drive keeps waking up around once in a minute. Monitoring with auditd has showed that the process that polls drives is /usr/lib/udisks/udisks-helper-ata-smart-collect. Now, I have removed HDD sensor from indicator and I can't hear any respins for about 15 minutes now.

Not sure where it should be fixed, in indicator-sensor or udisks, but I think that indicator-sensors should consider disk state and not poll it if it is idle.

Revision history for this message
Alex Murray (alexmurray) wrote :

I don't think this is a bug in indicator-sensors for 2 reasons:

1. We simply use udisks to query the temperature periodically - so udisks is doing the waking up of the disk, not indicator-sensors itself.
2. The disk has to be woken as far as I understand it to query the SMART properties of which the temperature is the one we want - there is no way around this. If you want to accurately know the temperature over time you have to do this querying.

I expect that to most users if they enable to monitor the temp of a HDD then they expect the temp value listed to be accurate - however if we don't query the temp since the disk is idle then they have no way of knowing that the temperature value is not accurate.

However, I can see a case that there could be a user configurable option to not do the query if the disk is already idle, but just to not enable this by default.

Revision history for this message
Alex Murray (alexmurray) wrote :

So I suggest perhaps raising a bug with udisks / investigating if there is a way for udisks to read the SMART data without waking the drive as well since this would be the best solution overall.

Revision history for this message
Igor Tarasov (tarasov-igor) wrote :

Ok, I gave it some thought and here is what I think.

I think that this is behavior of sensors indicator that should be changed and not udisk's. And here is why:

Imagine, you have a problem that reads something from disk. But generally, it is not necessary to read if drive is idle. But it keeps reading. The system wakes up drive in order to provide access to it. Who's to blame? The system or program?

While drive is idle sensor should display "idle" or "N/A" or "--" and do not try to poll the drive. This seems just logical. I can agree that this might be optional.

Also, I think that users should be informed once they add such sensor that it might prevent their drive from going idle when on battery. Esp. if there IS a battery in the system.

Revision history for this message
Alex Murray (alexmurray) wrote :
Changed in indicator-sensors:
status: New → Fix Committed
importance: Undecided → Medium
assignee: nobody → Alex Murray (alexmurray)
Revision history for this message
Alex Murray (alexmurray) wrote :

0.8 has now been released in the official PPA - and is in the daily PPA as well for 14.04, closing as complete.

Changed in indicator-sensors:
status: Fix Committed → Fix Released
Revision history for this message
Michele Giacomoli (michele-giacomoli) wrote :

Hi, I saw that gnome-disks can update the hdd temperature even if the disk is in standby and without waking it up. I think it uses SMART data. Maybe it's a bug in udisk

Revision history for this message
Alex Murray (alexmurray) wrote :

@Michele - can you provide more information about how gnome-disks does this? My understanding is that it simply uses udisks2 as the backend - and we already support this. Also the way we get temperature data from udisks / udisks2 is via SMART anyway - so basically we request udisks[2] to update the SMART data but to not wake the disk if idle - and then we read out the temperature value. I think this would be the same as what gnome-disks is doing.

Revision history for this message
Michele Giacomoli (michele-giacomoli) wrote :

@Alex - Sorry, I don't know how gnome-disks does, and I don't know udisks2 works too :(

Revision history for this message
Michele Giacomoli (michele-giacomoli) wrote :

I'm reading the gnome-disk-utility code. it seems it uses the udisks_drive_ata_get_smart_temperature() function from the udisks library (http://udisks.freedesktop.org/docs/latest/UDisksDriveAta.html#udisks-drive-ata-get-smart-temperature)

Revision history for this message
Alex Murray (alexmurray) wrote :

We also use that same API in the udisks2 plugin - https://github.com/alexmurray/indicator-sensors/blob/master/plugins/udisks2/is-udisks2-plugin.c#L141 - so I don't think indicator-sensors is doing anything wrong.

Revision history for this message
Michele Giacomoli (michele-giacomoli) wrote :

Ok, that is really strange!

Revision history for this message
Michele Giacomoli (michele-giacomoli) wrote :

@Alex - I downloaded the indicator-sensors source and tried to re-enable udisks2 to query the temperature of the idle disks, I put the disk to idle state and assured indicator-sensor to update his temperature (waiting for a change of it), then I opened gnome disks and checked in SMART data the value for start/stop cycles: it is the same of when I spun it down -> indicator-sensor didn't woke it up

@Igor - Can you please give some information about which distribution and version of it are you using? Can you try to put your disk to idle state open Gnome Disks and check if looking for (or updating) your drive temperature cause it to be spun up?

@Alex - I also attached the diff of is-udisks2-plugin.c that I modified in order to re-enable udisks to check the temperature for idle drives, maybe I did something wrong, but it works for me. It reads the temperature even if the disk is idle, and I don't get that ugly error message every time it tries to update its data any more.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.