PATCH: Forcible delaying of UFS (soft)updates

[Marko Zec]

David Schultz wrote:

> On Tue, Apr 15, 2003, Marko Zec wrote:
> >
> > > - The fiddling with rushjob seems rather arbitrary.  You can probably
> > >   just let the existing code increment it as necessary and force a sync
> > >   if the value gets too high.
> >
> > If rushjob is would not be used for forcing prompt synching, the original code
> > could not guarantee the sync to occur immediately. Instead, the synching could
> > be further delayed for up to 30 seconds, which is not desirable if our major
> > design goal is to do as much disk I/O as possible in a small time interval and
> > leave the disk idle otherwise.
>
> I was referring to all the places where rushjob is set to or
> incremented by syncer_maxdelay.  AFAIK, it should never be that
> large.

Hmm... Why? :)

> I don't think you want to overload a low memory handling
> mechanism with the task of syncing the disk.

As far as I can see the rushjob variable is used only at one place in
kern/vfs_subr.c to notify softupdates synching scheduler to start synching earlier
than the normal timers would expire. I just reused the same mechanism to urge
synching of dirty buffers when the extra delay timer expires, or when outstanding
disk I/O occurs, to coalesce disk updates with occasional disk spinups.

Marko