PATCH: Forcible delaying of UFS (soft)updates

[Marko Zec]

On Friday 18 April 2003 09:13, David Schultz wrote:
> 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.

True.

> If rushjob gets too high (half the maximum sync
> delay, usually 15), the system resorts to other measures.

Which measures, and in which cases? The only two chunks of code in the entire 
-stable kernel that probe the value of rushjob (indirectly through invoking 
speedup_syncer() ) are newdirrem() and inodedep_lookup() in 
ufs/ffs/ffs_softdep.c. Neither of these two will either corrupt a single bit 
of data or crash the system if rushjob gets higher than max syncdelay / 2.

> Your code bumps rushjob up by the arbitrary value 32, which is
> rather large.  Doing so is going to throw things out of whack.

Which things and how?

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

Sure, that's precisely why I increment rushjob - to instruct the syncer to 
start synching when I want it to. What's wrong with that?

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

If I'm not mistaking Warner was talking about using memory based FS and 
periodically synching it to a flash based device. Such a concept is perfectly 
sane for appliances using solid state disks, however I don't see how it can 
be applied to a typical laptop.

Marko