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