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

    \
     
     \ /
      Last update: 2005-03-22 13:57    [W:0.024 / U:59.956 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site