PATCH: Forcible delaying of UFS (soft)updates

[David Schultz]

On Sat, Apr 12, 2003, Marko Zec wrote:
> Here's a patch against 4.8-RELEASE kernel that allows disk writes on
> softupdates-enabled filesystems to be delayed for (theoretically)
> arbitrarily long periods of time. The motivation for such updating
> policy is surprisingly not purely suicidal - it can allow disks on
> laptops to spin down immediately after I/O operations and stay idle for
> longer periods of time, thus saving considerable amount of battery
> power.

Very nice!  I have been thinking about doing something like this
for a long time, but I never managed to find the time.  Some
comments:

- As others have mentioned, the fsync-disabling feature is questionable
  and ought to be separate.  You can make it somewhat more useful by at
  least guaranteeing transactional consistency, i.e. by treating every
  fsync() call as a write barrier.  You would need to ensure this for
  both data and metadata, which I expect would be devilishly hard to do
  within the softupdates framework.  However, you might be able to
  accomplish it at the disk buffer level.  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.

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

- Patches against -CURRENT would be nice.  (Sorry, that will be a doosie.)

- It looks like you have a few separate changes in there, such as
	+	TUNABLE_INT_FETCH("kern.maxvnodes", &desiredvnodes);
  and
	-	long starttime;
	+	time_t starttime;