Re: which process is accessing my hard drive?
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
>
>
Reply to: