Messages in this thread | | | Date | Mon, 31 Jul 2000 01:59:58 +0200 (CEST) | From | Daniel Kobras <> | Subject | Re: sync: why disk cannot spin down |
| |
On Mon, 31 Jul 2000, Xuan Baldauf wrote:
> this problem is possibly unrelated to reiserfs but related to > linux-kernel, but now I can prove it: regular sync()s do prevent the > spindown of (IDE) disks. There will be a call to sync() after 32 or less > seconds have elapsed since the last sync(). Not a problem itself, but > every sync spins up the disk again. > > The former shows that sync(2) (and therefore sync(1) respectively) makes > the disk spin up. The kernel|kupdate does seem to simply call sync() > too.
Yes, and that's perfectly fine. You're description is correct for a somewhat loose sense of sync(), not equal to sync(2), but meaning 'some call that will send buffers down the i/o request queue to the hardware'.
> Try following little script on you own, the example is run on a system > which was idle with a IBM-DHEA-36481 as /dev/hda:
That's where you are wrong: Your system is not idle at all. It's executing /bin/date, and it's executing /sbin/hdparm.
> desktop:~ # sync; hdparm -C -Y /dev/hda; while true; do date; hdparm -C > /dev/hda; sleep 2; done > > /dev/hda: > issuing sleep command > drive state is: standby > Sun Jul 30 21:16:59 CEST 2000 [snip] > /dev/hda: > drive state is: standby > Sun Jul 30 21:17:32 CEST 2000 > > /dev/hda: > drive state is: active/idle > Sun Jul 30 21:17:38 CEST 2000 > > 32 after the last sync, the disk is up again. Why, where it is not > necessary? Is it a bug?
Here is what happens: Your script generates loads of dirty buffers. How? It's all read-only? Not quite. Try the following:
while true; do /bin/date; ls -l -u /bin/date; sleep 60; done
Each invocation of /bin/date will update its atime, yielding a dirty buffer that kupdate will happily send down to the disk after some time, based on your bdflush settings. With a standard bdflush setup, kupdate wakes up every five seconds. Non-superblock dirty buffers have to age 30 seconds before they are ripe to be flushed to disk. So running your skript will send an i/o command to the disk after 30-35 seconds. The IDE bus reset necessary as you spun down your disk with hdparm -Y rather than hdparm -y takes a few seconds as well, yielding a total of 39 seconds for your drive to become active again.
The point being: If you want your disk to stay down, mount with option noatime, or <SPAM>use noflushd</SPAM>.
Regards,
Daniel.
-- GNU/Linux Audio Mechanics - http://www.glame.de GPG Key ID 89BF7E2B - http://www.keyserver.net
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |