From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.5)
Description of problem:
Disks that are in standby mode keep spinning up to active mode, even
when they aren't mounted.
Under FC2 with the same hardware the harddrives would stay in standby
mode until mounted and accessed.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Set an unmounted disk to "Standby" mode using hdparm -y
2. Check the status of the disk is standby using hdparm -C /dev/hdX
3. Wait a short while (less than 1 hour), the harddrive will spin up
and go into active mode (as reported by hdparm)
Actual Results: The harddrives spin up after a few minutes.
Expected Results: The harddrives should stay in standby mode until
mounted and accessed.
Is this related to the new HAL system?
possibly. 'something' is obviously accessing it, but what, I'm not sure.
To find out which process it is, kill the klogd process, and echo 1 to
/proc/sys/vm/block_dump After the disk spins up, dmesg should contain messages
about the process that accessed the disk.
I ran the test against one of my drives, /dev/hdc.
1 - Unmount /dev/hdc from its mount point
2 - echo 1 > /proc/sys/vm/block_dump
3 - Found and killed klogd
4 - Span the disk down using hdparm -y /dev/hdc
5 - Confirmed that disk was spun down using hdparm -C /dev/hdc
6 - Ran dmesg to confirm that disk accesses were being logged.
7 - Waited until the disk spun up, confirmed using hdparm -C /dev/hdc
8 - Ran dmesg catpturing output to a file.
The file contains no references to hdc, only to processes accessing
hda (the root and home file systems).
Dave: I can supply the log file via email if you want.
what processes are accessing the disk ? This bug should be filed against those.
There were *NO* references to hdc being accessed by any process when I
had /proc/sys/vm/block_dump set to 1.
This indicates to me that either the kernel IDE driver spins the disk
up, or some process accessed the disk through a kernel interface that
bypasses the block access layer.
Is there any interface that a process can use to access the disk,
without any log entry being made into dmesg with block_dump set to 1?
If there is, what if anything can be done to determine the process
calling such an interface?
Had the same here. Here the culprit was smartd. It spins up disks
each 30 minutes to do its test. You can ask it not to spin up
disks in standby (add "-n standby") to /etc/smartd.conf, then restart
I think that option ought to be default ...
Thanks for the tip Bert - that solves the problem for me as well.
I'm changing the component to 'kernel-utils' which is the package that
smartd resides in.
future versions of smartd won't start up by default (for various other reasons).