Date: Fri, 18 Apr 2003 05:49:14 -0700 From: David Schultz <das@FreeBSD.ORG> To: Terry Lambert <tlambert2@mindspring.com> Cc: Kirk McKusick <mckusick@beastie.mckusick.com> Subject: Re: PATCH: Forcible delaying of UFS (soft)updates Message-ID: <20030418124914.GA10979@HAL9000.homeunix.com> In-Reply-To: <3E9F4413.D294E69E@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>
next in thread | previous in thread | raw e-mail | index | archive | help
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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030418124914.GA10979>