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

[Chris Mason <mason@suse.com>]

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