PATCH: Forcible delaying of UFS (soft)updates

[Marko Zec]

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. 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?

> 
> Under what circumstances you you find that delaying fsync()
> helps you?  What program are you running that calls fsync()?

The vi editor, pretty much every e-mail client, and so on...

> Even if you don't use it for a
> statistical check, it will check you on the number of times
> fsync() (and sync()) get called by someone. If it's a small
> number, you need to fix the bogus program, rather than hack
> the kernel.  8-).

No, those programs are not bogus, and neither is the kernel. I just want to 
have a method to keep the damn disk spinned down, that's all.

Marko