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/
This archive was generated by hypermail 2b29 : Mon Jul 31 2000 - 21:00:32 EST