Re: Kernel 2.2.14, dirty buffers, stalls in interactivity of system/NFS-clients ...

From: Richard B. Johnson (root@chaos.analogic.com)
Date: Wed Mar 29 2000 - 10:25:09 EST


On Wed, 29 Mar 2000, Bryan -TheBS- Smith wrote:

> On Tue, 28 Mar 2000, Daniel J Blueman wrote:
[SNIPPED...]

>
> > This large flush every 30s
>
> Actually, these large "flushes" happen only occassionally (every 30
> minutes), but for 15-60s. That's the problem.
>

I found that the large flushes, taking a long time, made my workstation
a bit temperamental so I run a little daemon that does what bdflush used
to do:

for(;;)
{
    sync();
    sleep(30);
}

This keeps the size of the flushes down on a machine that has lots of
RAM. It seems that the default, with a machine that has lots of RAM
is to use that RAM for the virtual file-systems. When a flush finally
occurs, it can take a lot of time.

It also takes a lot of time to `umount` a file-system when there are
a lot of buffers to be written. This was not much of a problem in
the 16 megabyte or RAM days. Now, where most everybody has hundreds
of megabytes, a major portion of this has to be written to storage
during the umount/shutdown sequence.

Perhaps we need another tunable parameter (max fs cache) or something
like that?

Cheers,
Dick Johnson

Penguin : Linux version 2.3.41 on an i686 machine (800.63 BogoMips).

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



This archive was generated by hypermail 2b29 : Fri Mar 31 2000 - 21:00:24 EST