Description of problem:
I booted F11/rawhide to runlevel 1, and confirmed that nothing was polling my second drive (via "sysctl -w vm.block_dump=1"), /dev/sdb, which is normally only mounted for backups.
However, I could not spin it down. Every time it went to spin down, I
heard it spin up again immediately (confirmed with 'hdparm -C'). Even manually (via 'hdparm -y'), the drive immediately spun back up.
I booted a F10 liveCD, and the drive spins down no problem.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1.Verify SMART is off in BIOS
2.Boot to single user mode to insure nothing is polling the drive
3.hdparm -S1 /dev/sdb and/or hdparm -y /dev/sdb
Drive does not spin down
Drive spins down
Additional info: Works in F10
bug 454582 comment 5 may be related.
This bug appears to have been reported against 'rawhide' during the Fedora 11 development cycle.
Changing version to '11'.
More information and reason for this action is here:
I had a script that did sleep my 2nd hard disk with "hdparm -y /dev/sdb"
In Fedora 10 is was working and after the upgrade to Fedora 11 it did spin down but spins up right away.
There is a bug listed in the debian bug tracker that's about the same problem.
If I am right, it's about hdparm en pulling the drive to often via udev.
I couldn't find a rpm of hdparm version >= 9.15.
1 So I downloaded the source of hdparm
3 make install
and my problem is gone. The drive is quite noisy...
I hope this comment helps someone.
I tried hdparm 9.15, and the drive is going idle now. However, it is being brought active again after a few seconds. Perhaps udev should skip polling drives that are unmounted and spun-down? Or perhaps limit the polling on these drives to once a day and at boot?
(In reply to comment #0)
> However, I could not spin it down. Every time it went to spin down, I
> heard it spin up again immediately (confirmed with 'hdparm -C').
actually, because of the nature of the hdparm bug, hdparm -C is another cause of the drive spinning up.
> Version-Release number of selected component (if applicable):
this bug is incorrectly filed as a kernel bug
see also bug #507963 and bug #511936
Even though this bug was filed first :) I think duping it to 507963 is the right answer since that's a bit more descriptive, and on the right component.
*** This bug has been marked as a duplicate of bug 507963 ***