Re: spindown no longer working after upgrade from etch -> lenny
You can user the laptop-mode-tools for diagnostics, especially
lm-profiler for hints who is accessing the disks.
BTW:
Linux thecus 2.6.26-1-iop32x #1 Mon Dec 15 19:33:14 UTC 2008 armv5tel
GNU/Linux
is the kernel I am using, and its sleeping a lot ;-)
thecus:/home/tobi# cat /tmp/frostynasstat/hdd_sda_stat
Device:/dev/sda
State:active
LastKnownTemperature:520
EstimatedTemperature:520
TotalSleep:485574
TotalActive:156680
TotalUnknown:0
Spinups:28
DateStamp:"Sun Jan 25 23:09:29 2009"
DateLastKnownTemp:"Sun Jan 25 23:09:29 2009"
AverageSleep:17341
AverageActive:5595
thecus:/home/tobi#
On Sun, 2009-01-25 at 23:10 +0100, Markus Ulbricht wrote:
> Hi Matt,
>
> thanks for the answer.
> Since spindown was working properly with debian etch
> the noatime mount option was already set.
> So I still guess something with hddtemp is now built
> into the kernel?
> If I send the hdd to spindown with
>
> /usr/bin/sg_start 0 /dev/sda
>
> it wakes up after about 4 or 5 minutes and I need
> to check out which process might be responsible for that.
>
> Can give me anyone a hint what I have to check?
>
> Markus
>
> Matthew Palmer schrieb:
> > On Sat, Jan 24, 2009 at 09:57:29PM +0100, Markus Ulbricht wrote:
> >
> >> Hi all!
> >>
> >> Since hdd performance of the Thecus N2100 is not so
> >> perfect with debian etch (stable, kernel 2.6.18) I did
> >> an upgrade to lenny with kernel 2.6.26 including the
> >> DMA patches by Martin Michlmayr.
> >>
> >> Thanks to Martin the hard drive performance is now
> >> much better (173 MB/s cached / 48 MB/s buffered reads).
> >>
> >> Unfortunately hdd spindown is no longer working.
> >>
> >
> > Oooh, I've been here. My problem turned out to be atime updating; I had a
> > process that was reading a file every 30 seconds or so, which then caused
> > the atime on that file to be updated and hence the disk was never spinning
> > down. Remounting with noatime did the trick.
> >
> > Assuming that isn't it, it's unlikely that you'll be running enough
> > processes to make finding the culprit by killing things one-by-one
> > impractical.
> >
> >
> >> Since I am not so familiar with kernel (re)compilation I am not able
> >> to create an appropriate kernel needed for tools like atop which is able
> >> to report processes responsible for disk i/o.
> >>
> >
> > Rebuilding a kernel isn't hard, but it does take a little while, so I'd go
> > with other investigation methods first.
> >
> > - Matt
> >
> >
> >
>
>
Reply to: