On Friday, February 22, 2002 10:57:51 AM -0500 James Bottomley <James.Bottomley@steeleye.com> wrote:
[ very interesting stuff ]
> 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 is my requirement for reiserfs, where I still want to wait on the
commit block to check for io errors. sct might have other plans.
> This means that it doesnt matter if later
> commands move through the barrier, it only matters that earlier commands
> cannot move past it? If this is true, then we can fix the slot problem simply
> by having a slot dedicated to barrier tags, so the processing engine goes over
> it once per cycle. However, if it finds the barrier slot full, it doesn't
> issue the command until the *next* cycle, thus ensuring that all commands sent
> down before the barrier (plus a few after) are accepted by the device queue
> before we send the barrier with its ordered tag.
Interesting, certainly sounds good.
-chris
-
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