Hide Forgot
From Bugzilla Helper: User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.5) Gecko/20041107 Firefox/1.0 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): kernel-2.6.9-1.667 How reproducible: Always 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. Additional info: 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. Steps: 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 smartd. 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).