Date: Fri, 18 Apr 2003 11:12:01 -0700 From: Terry Lambert <tlambert2@mindspring.com> To: David Schultz <das@FreeBSD.ORG> Cc: Kirk McKusick <mckusick@beastie.mckusick.com> Subject: Re: PATCH: Forcible delaying of UFS (soft)updates Message-ID: <3EA03FF1.280B6810@mindspring.com> References: <200304162310.aa96829@salmon.maths.tcd.ie> <3E9E9827.4BB19197@tel.fer.hr> <3E9EDC38.1CE381C6@mindspring.com> <200304172143.26387.zec@tel.fer.hr> <3E9F4413.D294E69E@mindspring.com> <20030418124914.GA10979@HAL9000.homeunix.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3EA03FF1.280B6810>