Re: [PATCH] 2.4.x write barriers (updated for ext3)

Chris Mason
2002-02-22T16:11:29Z

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