PATCH: Forcible delaying of UFS (soft)updates

[David Schultz]

On Tue, Apr 15, 2003, Marko Zec wrote:
> David Schultz wrote:
> 
> >   For instance, you could
> >   have fsync() push the appropriate dirty buffers out to a separate
> >   cache, then commit the contents of the cache in the order of the
> >   fsyncs when the disk is next active.
> 
> Huh... such a concept would still break fsync() semantics. Note that the
> original patch also ensures dirty buffers get flushed if / when the disk spins
> up, even before the delay timer gets expired.

I didn't say it wouldn't still break fsync() semantics; it
doesn't.  However, you could guarantee that data are in a
consistent state with my proposal.  On the other hand, the more I
think about the details, the more I think this could be more of a
pain than it's worth.


> 
> > - 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.  I don't think you want to overload a low memory handling
mechanism with the task of syncing the disk.