PATCH: Forcible delaying of UFS (soft)updates

[Terry Lambert]

Marko Zec wrote:
> On Friday 18 April 2003 03:07, Terry Lambert wrote:
> > No, you are missing my previous point: the check for free space
> > should include a check for number of elements *TOTAL* in all slots
> > on the soft updates timer wheel.  Otherwise it can eat all of
> > memory.
> >
> > The free space check only works in the case that you've done a
> > delete and are allocating new space: the case where you are doing
> > more and more allocations/opverwrites of data is not handled, and
> > can grow to eat all available kernel memory.  There was in fact a
> > bug, early on, that Matt Dillon worked around that caused it under
> > load, and it was in exactly the code you are touching.
> 
> If what you are saying were true, than one could simply crash an _unpached_
> system by doing a lot of FS write operations.

No.  See the checkin comments for "rushjob".

> What my patch does is that it
> just temporarily suspends the softupdates "wheels" as you call it. However,
> if VM or another ffs subsytem indicates (by increasing the value of rushjob)
> that buffers should get flushed more frequently, than my patch will
> _immediately_ drop out of the delay loop and allow the syncing to proceed
> ASAP. I really do not see what can be wrong with such a concept?

No.  See last posting: the wheel can not be allowed to "wrap".

-- Terry