> 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
Does the following patch help a bit in those scenarios?
(it looks as if those two lines were supposed to be there by design --
they perfectly match the existing comment above them :-)
Gadi
--- linux/fs/buffer.c~ Mon May 5 14:55:14 1997
+++ linux/fs/buffer.c Mon May 5 14:55:14 1997
@@ -676,6 +676,8 @@
* now so as to ensure that there are still clean buffers available
* for user processes to use (and dirty).
*/
+ while(nr_buffers_type[BUF_DIRTY] > nr_buffers * bdf_prm.b_un.nfract/100)
+ wakeup_bdflush(1);
/* We are going to try to locate this much memory. */
needed = bdf_prm.b_un.nrefill * size;