PATCH: Forcible delaying of UFS (soft)updates

[David Schultz]

On Thu, Apr 17, 2003, Marko Zec wrote:
> 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.

When the system is low on memory or has reached a related limit,
it tries to sync data to disk faster by slowly increasing the
value of rushjob until the situation improves.  If the syncer is
able to keep up, it will process data faster and pull rushjob back
down to zero.  If rushjob gets too high (half the maximum sync
delay, usually 15), the system resorts to other measures.

Your code bumps rushjob up by the arbitrary value 32, which is
rather large.  Doing so is going to throw things out of whack.
What you would probably want to do is leave rushjob alone.  If it
ever becomes nonzero, the syncer should wake up and start writing
again.  If you would like to write the data out more quickly
whenever the disks start up so you can make them spin down again,
look at softdep_request_cleanup() in -CURRENT.

But really, even getting fsync() to do *remotely* the right thing
(i.e. correct ordering but no guarantee of writing data to stable
storage when in power save mode) is going to be *really*hard*.
Warner has a much better suggestion.