lkml.org 
[lkml]   [1997]   [May]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: Badblocks and no free pages...
Date
Sun, 4 May 1997 Doug Ledford wrote:>
>> Can I report the following as bugs:
>> - The fact that badblocks doesn't help prevent accidents is a bit unfortunate.
>> - The fact that it generates "Couldn't get a free page" seems bad.
>> In particular, why should this happen during writing? What needs to
>> do an atomic page allocation?
>
>It's all because we are filling up all available RAM with write behind
>buffers. Whenever it can't get a free page, it simply waits for some to
>become available. Not a bug really, just shows us that the program is
>writing as fast as it can.
>
>> - The unusable sluggishness of the machine is a bug.
>
>It was never intended to be something that you would run during normal
>usage, it's a shake down, tear the drives and controllers apart type test
>that should be run when you are aware of what these types of tests do to
>machine performance and are prepared to wait for it to finish before
>actually trying to do anything :)

I noticed something alike when doing "mke2fs" on a 9GB volume in 2.0.28.
Is there a way to limit write behind buffers so more memory is available
for other uses. Allocating more than eg. 2Mbyte per device won't speed things
up I think. Programs like "badblocks" or "mke2fs" will use all available
space for buffering.

Chel

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