Hi,
On Fri, Feb 22, 2002 at 10:57:51AM -0500, James Bottomley wrote:
> Finally, I think the driver ordering problem can be solved easily as long as
> an observation I have about your barrier is true. It seems to me that the
> barrier is only semi permeable, namely its purpose is to complete *after* a
> particular set of commands do. This means that it doesnt matter if later
> commands move through the barrier, it only matters that earlier commands
> cannot move past it?
No. A commit block must be fully ordered.
If the commit block fails to be written, then we must be able to roll
the filesystem back to the consistent, pre-commit state, which implies
that any later IOs (which might be writeback IOs updating
now-committed metadata to final locations on disk) must not be allowed
to overtake the commit block.
However, in the current code, we don't assume that ordered queuing
works, so that later writeback will never be scheduled until we get a
positive completion acknowledgement for the commit block. In other
words, right now, the scenario you describe is not a problem.
But ideally, with ordered queueing we would want to be able to relax
things by allowing writeback to be queued immediately the commit is
queued. The ordered tag must be honoured in both directions in that
case.
There is a get-out for ext3 --- we can submit new journal IOs without
waiting for the commit IO to complete, but hold back on writeback IOs.
That still has the desired advantage of allowing us to stream to the
journal, but only requires that the commit block be ordered with
respect to older, not newer, IOs. That gives us most of the benefits
of tagged queuing without any problems in your scenario.
--Stephen
-
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/
This archive was generated by hypermail 2b29 : Sat Feb 23 2002 - 21:00:42 EST