[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:4.209 / U:0.216 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site