PATCH: Forcible delaying of UFS (soft)updates

Terry Lambert tlambert2 at mindspring.com
Fri Apr 18 11:13:36 PDT 2003


David Schultz wrote:
> > 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 it sits, the implementation is via a timer that is not under
OS control.  It would be nice if it used this method, instead,
since it would allow anyone who wanted to to implement a "policy",
if the default policy bothered them (e.g. do it when the screen
saver kicks on, or do it when there haven't been any mouse/keyboard
input events for XX seconds, etc. -- you could even hook this to
whether the delayed fsync is active or not, which seems a better
time for it to be active, anyway).


> As for the ATA delayed write feature, I don't believe it will
> guarantee consistency.

It doesn't.  I checked, after voicing my suspions of it.

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

You can't turn the reordering off, and your example is exactly
the "barrier" case I had previously described.  8-).

-- Terry


More information about the freebsd-stable mailing list