Re: (reiserfs) Re: sync: why disk cannot spin down

[Xuan Baldauf <xuan--reiserfs@baldauf.org>]

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)



-
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/