Hello,
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.
You can verify by this by running this script:
desktop:~ # sync; date; hdparm -C -Y /dev/hda; date; sleep 2; hdparm -C
/dev/hda; date; sync; date; hdparm -C /dev/hda
Sun Jul 30 21:24:57 CEST 2000
/dev/hda:
issuing sleep command
drive state is: standby
Sun Jul 30 21:24:58 CEST 2000
/dev/hda:
drive state is: standby
Sun Jul 30 21:25:00 CEST 2000
Sun Jul 30 21:25:03 CEST 2000
/dev/hda:
drive state is: active/idle
desktop:~ #
If you see the second standby, you fairly can be sure that immediately
before calling "sync", the disk is spun down. After calling sync, the
disk is up. You can also strace the second sync, you will see that it
will lag at the sync() call, just before exiting.
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.
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:
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:01 CEST 2000
/dev/hda:
drive state is: standby
Sun Jul 30 21:17:03 CEST 2000
/dev/hda:
drive state is: standby
Sun Jul 30 21:17:05 CEST 2000
/dev/hda:
drive state is: standby
Sun Jul 30 21:17:07 CEST 2000
/dev/hda:
drive state is: standby
Sun Jul 30 21:17:09 CEST 2000
/dev/hda:
drive state is: standby
Sun Jul 30 21:17:11 CEST 2000
/dev/hda:
drive state is: standby
Sun Jul 30 21:17:13 CEST 2000
/dev/hda:
drive state is: standby
Sun Jul 30 21:17:15 CEST 2000
/dev/hda:
drive state is: standby
Sun Jul 30 21:17:17 CEST 2000
/dev/hda:
drive state is: standby
Sun Jul 30 21:17:19 CEST 2000
/dev/hda:
drive state is: standby
Sun Jul 30 21:17:21 CEST 2000
/dev/hda:
drive state is: standby
Sun Jul 30 21:17:23 CEST 2000
/dev/hda:
drive state is: standby
Sun Jul 30 21:17:25 CEST 2000
/dev/hda:
drive state is: standby
Sun Jul 30 21:17:27 CEST 2000
/dev/hda:
drive state is: standby
Sun Jul 30 21:17:29 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
/dev/hda:
drive state is: active/idle
Sun Jul 30 21:17:40 CEST 2000
/dev/hda:
drive state is: active/idle
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:17:43 CEST 2000
/dev/hda:
drive state is: standby
Sun Jul 30 21:17:45 CEST 2000
/dev/hda:
drive state is: standby
Sun Jul 30 21:17:47 CEST 2000
/dev/hda:
drive state is: standby
Sun Jul 30 21:17:49 CEST 2000
/dev/hda:
drive state is: standby
Sun Jul 30 21:17:51 CEST 2000
/dev/hda:
drive state is: standby
Sun Jul 30 21:17:53 CEST 2000
/dev/hda:
drive state is: standby
Sun Jul 30 21:17:55 CEST 2000
/dev/hda:
drive state is: standby
Sun Jul 30 21:17:57 CEST 2000
/dev/hda:
drive state is: standby
Sun Jul 30 21:17:59 CEST 2000
/dev/hda:
drive state is: standby
Sun Jul 30 21:18:01 CEST 2000
/dev/hda:
drive state is: standby
Sun Jul 30 21:18:03 CEST 2000
/dev/hda:
drive state is: standby
Sun Jul 30 21:18:05 CEST 2000
/dev/hda:
drive state is: standby
Sun Jul 30 21:18:08 CEST 2000
/dev/hda:
drive state is: standby
Sun Jul 30 21:18:10 CEST 2000
/dev/hda:
drive state is: standby
Sun Jul 30 21:18:12 CEST 2000
/dev/hda:
drive state is: standby
Sun Jul 30 21:18:14 CEST 2000
/dev/hda:
drive state is: active/idle
Sun Jul 30 21:18:21 CEST 2000
32 after the last sync, the disk is up again. Why, where it is not
necessary? Is it a bug?
The system is reiserfs3.6.11 on linux-2.4.0-test5.
Xuân. :o)
-
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:31 EST