Xuan Baldauf wrote:
> Russell King wrote:
>
> > Xuan Baldauf writes:
> > > 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 may want to have a look at the atime/diratime mount options, or
> > even chattr -A to prevent certain files causing a write when they're
> > run/read.
> >
> > Note that just executing "sync" causes its atime to be marked for update,
> > which will cause a write back to disk a short while later.
> >
> > [...]
>
> Thank you for waking me! :o) I forgot the atime issue. I wonder why it still
> is the default...
>
Now I made all my partitions noatime, and wow,
sync; hdparm -C -Y /dev/hda; sync; hdparm -C /dev/hda
does not necessarily spin up the disk!
Someone suggested noflushd (does anybody have pointers?), because every write
would trigger spin up, but that is okay for me, I'd like to have a system where
no writes are done else when needed. About a minute (some more or less seconds)
after spindown, the disk spins up again, but now I cannot find out the cause.
I tried to strace the whole system with
strace `ps x|grep -v PID|grep -v $PPID|awk {' print "-" "p " $1 '}`
but this was not very clueful, because if some process writes, the buffers are
only changed in memory. Then the disk spins down (spindown time set to 20
seconds). After some time, the disk spins up again, because kupdate sends the
buffers to disk. Unfortunately, this way I cannot find (time-)relations between
writes or write-like functions (like munmap) and disk access.
Is there a simple switch or a patch out there which makes every buffer (head)
release synchronous (yet not discarding the buffer, it is still needed so all
daemons can fully run in RAM).
Xu?n.:o)
On Mon, 31 Jul 2000, Xuan Baldauf wrote:
> Now I made all my partitions noatime, and wow,
>
> sync; hdparm -C -Y /dev/hda; sync; hdparm -C /dev/hda
>
> does not necessarily spin up the disk!
Because you have to issue a drive reset.
Andre Hedrick
The Linux ATA/IDE guy
On Mon, 31 Jul 2000, Xuan Baldauf wrote:
> Xuan Baldauf wrote:
> sync; hdparm -C -Y /dev/hda; sync; hdparm -C /dev/hda
Note that "sleep" mode is quite different from "standby" mode. Drives
spin up from standby mode by themselves, they are NOT supposed to wake
up from sleep mode, unless you issue a reset.
Sleep mode is meant to put the drive to sleep, possibly switching the
laptop off or something.
We happen to be so lucky that the Linux kernel issues a reset if it is
fed up with IDE timeouts, which will bring the drive back online, at the
expense of voiding all settings in that IDE channel, particularly, DMA
modes, PIO modes and the like, unless you use the "keep options over
reset flag". (which means soft reset, effectively).
Admittedly, drives should use less power in sleep mode, the price is
higher latency and, as said before, possibly loss of drive
configuration.
--
Matthias Andree