lkml.org 
[lkml]   [2000]   [Mar]   [29]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Kernel 2.2.14, dirty buffers, stalls in interactivity of system/NFS-clients ...
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/

\
 
 \ /
  Last update: 2005-03-22 13:57    [W:0.281 / U:0.020 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site