On Mon, Mar 01, 2004 at 07:55:09PM +0100, Mika Fischer wrote: > Mika Fischer wrote: > > I don't know the details but I was under the impression that the > > "laptop-mode" patch to the linux kernel included the ability to have the > > process waking up the disk logged. > > > > That might come in handy if it's true. > > > > Anyone know more about this? > > Here it is: > http://www.linuxhq.com/kernel/v2.4/23/Documentation/laptop-mode.txt
This is interesting and also suggests some other possibilities, which unfortunately I don't quite understand. Quoting from the text: > One problem is the age time of dirty buffers. Linux uses 30 seconds per > default, so if you dirty any data then flusing of that data will commence > at most 30 seconds from then. Another is the journal commit interval of > journalled file systems such as ext3, which is 5 seconds on a stock kernel. > Both of these are tweakable either from proc/sysctl or as mount options > though, and thus partly solvable from user space. > The kernel update daemon (kupdated) also runs at specific intervals, flushing > old dirty data out. Default is every 5 seconds, this too can be tweaked > from sysctl. Anyone know how to tweak kupdated or the "dirty buffer" "flushing" time using sysctl? Unfortuantely I don't even really knwo what these phrases mean (I can sorta guess)... I tried "sysctl -a" but the output wasn't particularly meaningful to me, and grep -i update produced no output. Anyone have ideas here? > So what does the laptop mode patch do? It attempts to fully utilize the > hard drive once it has been spun up, flushing the old dirty data out to > disk. Instead of flushing just the expired data, it will clean everything. > When a read causes the disk to spin up, we kick off this flushing after > a few seconds. This means that once the disk spins down again, everything > is up to date. That allows longer dirty data and journal expire times. This sounds cool -- though I probably won'th ave an opportunity to recompile the kernel in the next little while (among other problems, I'm at 97% fulll on /dev/hda...). But maybe the issues can be fixed using sysctl > > HTH, > Mika > >
