PATCH: Forcible delaying of UFS (soft)updates

[David Schultz]

On Thu, Apr 17, 2003, Terry Lambert wrote:
> Marko Zec wrote:
> > > You are much better off accumulating requests in the kernel in
> > > buffers, and then using the normal write mechanism to push them
> > > out to the drive ordered (IMO).
> > 
> > That is precisely what the original OS-controlled delayed synching patch does
> > :)
> 
> Yeah, but the spin-down isn't really under OS control, except
> as a sort of statistical hysteresis thing.  8-).

The OS can know exactly when the disk is spinning if it tells the
disk not to timeout all by itself with the IDLE command, and
explicitly tells it to IDLE IMMEDIATE at the appropriate time.
But being exact about this isn't particularly important.

As for the ATA delayed write feature, I don't believe it will
guarantee consistency.  This is true even if the drive doesn't
reorder writes, which it is free to do.  Consider a correctness
constraint given by the partial ordering of blocks A->B->A.  That
is, we have to first make a change to block A, then update block
B, then make a different change to block A.  This is going to be
fairly common if a fair number of writes are queued; it happens
whenever an editor saves a file using the correct fsync/rename
sequence, for instance.  The disk will coalesce the two writes to
A in its cache and therefore violate the constraint.