[lkml]   [2000]   [Jul]   [30]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: 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
> /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>.



GNU/Linux Audio Mechanics -
GPG Key ID 89BF7E2B -

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:57    [W:0.064 / U:1.664 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site