Messages in this thread | | | From | Daniel Phillips <> | Subject | Re: [PATCH] 2.4.x write barriers (updated for ext3) | Date | Mon, 4 Mar 2002 20:48:02 +0100 |
| |
On March 4, 2002 07:05 pm, Stephen C. Tweedie wrote: > Hi, > > On Mon, Mar 04, 2002 at 12:16:35PM -0500, Chris Mason wrote: > > > writeback data order is important, mostly because of where the data blocks > > are in relation to the log. If you've got bdflush unloading data blocks > > to the disk, and another process doing a commit, the drive's queue > > might look like this: > > > > data1, data2, data3, commit1, data4, data5 etc. > > > > If commit1 is an ordered tag, the drive is required to flush > > data1, data2 and data3, then write the commit, then seek back > > for data4 and data5. > > Yes, but that's a performance issue, not a correctness one. > > Also, as soon as we have journals on external devices, this whole > thing changes entirely. We still have to enforce the commit ordering > in the journal, but we also still need the ordering between that > commit and any subsequent writeback, and that obviousy can no longer > be achieved via ordered tags if the two writes are happening on > different devices.
But the bio layer can manage it, by sending a write barrier down all relevant queues. We can send a zero length write barrier command, yes?
-- Daniel - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |