Bug 138840 – Disks keep spinning up

Bugzilla will be upgraded to version 5.0 on a still to be determined date in the near future. The original upgrade date has been delayed.

Bug 138840 - Disks keep spinning up

Summary:	Disks keep spinning up

Status:	CLOSED ERRATA

Aliases:	None

Product:	Fedora
Classification:	Fedora
Component:	kernel-utils (Show other bugs)
Sub Component:
Version:	3
Hardware:	i686 Linux

Priority	medium Severity medium
Target Milestone:	---
Target Release:	---
Assigned To:	Dave Jones
QA Contact:
Docs Contact:

URL:
Whiteboard:
Keywords:

Depends On:
Blocks:
	Show dependency tree / graph

Reported:	2004-11-11 10:06 EST by Colin Stewart
Modified:	2015-01-04 17:11 EST (History)
CC List:	4 users (show)

See Also:
Fixed In Version:
Doc Type:	Bug Fix
Doc Text:
Story Points:	---
Clone Of:
Environment:
Last Closed:	2005-09-05 02:37:04 EDT
Type:	---
Regression:	---
Mount Type:	---
Documentation:	---
CRM:
Verified Versions:
Category:	---
oVirt Team:	---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---

Attachments	(Terms of Use)
Add an attachment (proposed patch, testcase, etc.)

Groups: None (edit)

Description Colin Stewart 2004-11-11 10:06:19 EST

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?

Comment 1 Dave Jones 2004-11-13 23:16:41 EST

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.

Comment 2 Colin Stewart 2004-11-14 12:27:07 EST

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.

Comment 3 Dave Jones 2004-11-15 23:38:27 EST

what processes are accessing the disk ? This bug should be filed against those.

Comment 4 Colin Stewart 2004-11-15 23:55:16 EST

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?

Comment 5 Bert DeKnuydt 2004-11-25 08:32:31 EST

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

Comment 6 Colin Stewart 2004-11-26 13:27:43 EST

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.

Comment 7 Dave Jones 2004-11-27 01:14:47 EST

future versions of smartd won't start up by default (for various other reasons).

Note You need to log in before you can comment on or make changes to this bug.