Bugzilla – Bug 346194
prevent hard and dvd drive from unnecessary spinups
Last modified: 2010-11-26 12:41:23 UTC
On a system with two hard disks the second disk /dev/sdb spins up from time to time although no file or swap partition is mounted fromout of that drive. This is ala long not good for the physics of that drive and can be very annoying because /dev/sdb is quite noisy; hdparm -Y /dev/sdb helps up to the next spinup (openSuse 10.3; smartctl already mentions a worsened spinup time; maybe because of continuing multiple unnecessary spinups). Similarely on a notebook under Suse10.1 a cdrom is spinned up multiple times during the boot process, if any is inserted, although there is no reason to access the cd during boot time (noisy, slows the boot process down). There should not be any program accessing a drive without mounted partitions. Is there any?
As far as I can remember this problem has not existed in previous versions of OpenSuse. On a computer with 1GB of RAM powered by Suse9.3 the hard disk spinned down a few minutes after finishing the boot process and from thereon allowed to work merely out of the memory without any singleton disk access for hours. Unnecessary disk activity is not only an annoyance but does pose a major drawback to mobile computing due to increased power consumption and worsened shock resistence of disks.
This is a HAL issue, probing the disk. There is an option to disable it, but I don't know where. Reassigning to the GNOME developers, they know where it is...
Danny, could this be caused by probing the volume size? We use the hal libraries to do that in GNOME. Not sure if the reporter is using GNOME/KDE or no gui at all.
1.) spin-up the CD/DVD drive is needed to get info about the media in the device and hal need to access the device regularly every few seconds to check if there is a media change, but this should not spin up the CD/DVD device. 2.) for the internal HD: hal should not access the device regulary - only at startup. You can check this by "ps aux | grep hald-addon-storage". There should be the info which devices get polled. So I would tip it's not HAL preventing the HD from spin down.
In deed it does not seem to be HAL (internal HD): > ps aux | grep hald-addon-storage 0 grep hald-ad root 2273 0.0 0.1 3276 1136 ? S 18:12 0:00 hald-addon-storage: polling /dev/sr0 (every 2 sec) root 2276 0.0 0.1 3276 1136 ? S 18:12 0:00 hald-addon-storage: polling /dev/sr1 (every 2 sec) root 4924 0.0 0.0 2988 744 pts/3 R+ 18:59 0:00 grep hald-addon-storage > grep sr /etc/fstab 0.0 2988 7 /dev/sr0 /media/dvd auto noauto,user,sync 0 0 /dev/sr1 /media/dvd2 auto noauto,user,sync 0 0
Alike the CD-on-boot-spinup issue still exists under Suse10.3(hal-0.5.9_git20070831-13.2). Nevertheless issuing > hdparm -y /dev/sr0 /dev/sr0: issuing standby command will persuade the drive to keep quiet. The cd does not get automounted on boot: > mount|g sr > ...
A singleton measurement of the auto-spindown throughout to the unmotivated-spinup delay period has yielded exactly 20 minutes.
This bug hasn't even been assigned yet, can someone please take it on or close if resolved ? No activity for 4 month, doesn't exactly look like P2 to me.. If no activity wizhin 21 days, will close as NORESPONSE, feel free to reopen if necessary. Thanks for reporting !
This thing is definitely dead :-( Closing.
Why not revitalize this issue. It applies to new eSATA hard disks as well. Even if lsof does not display anything the drive will spin up after a while as long as it is mounted.
(In reply to comment #10) > Why not revitalize this issue. It applies to new eSATA hard disks as well. Even > if lsof does not display anything the drive will spin up after a while as long > as it is mounted. I guess we would really need to know which program is causing this. Without this information, there's not much we can do. Can you try to find this out?
I would lovingly try! However I don`t really know on how to approach this issue. Perhaps we could mirror the /dev node of an eSATA disk and trace back any access attempts. Unfortunately I have no clue on how to accomplish this.
10.3 is obsolete now and there was not enough information for this bug to get fixed. I'll close this as NORESPONSE. If you can still reproduce it in 11.3 or a milestone of 11.4, please reopen the bug and move it to the appropriate product. Thanks!