> > > What is the point of having a B_ORDERED flag if the target device is,
> > > ultimately, allowed not to treat it as a barrier?
> > 
> > Because the *filesystem* or the *driver* can do the barrier.
> 
> How, by waiting for all the previous writes to complete, at the drive's
> leisure?  Even that seems prone to failure: if you look at the Linux 
> BusLogic driver you'll find a comment about issuing an ordered tag every 30
> seconds because the author had encountered drives which *never* wrote some
> simple tags otherwise (it's been suggested to me that this isn't legal 
> default behaviour, but might be triggered by certain mode page settings on 
> some popular drives).
> 
> In any case this seems... highly suboptimal.

It ain't a perfect world.

> 
> ISTM the correct simpleminded solution is to read using simple tags and 
> write using ordered tags; a slightly more sophisticated strategy would

I'm told that this is what the NCR driver does- I haven't checked for
myself. See below ...

> be to use simple tags for B_ASYNC buffers and ordered tags for other
> (sync) buffers, and the best is probably what we're talking about, 
> adding B_ORDERED and propagating it down to the driver.  But actually, 
> I'm curious.  Instinctively, I think the middle solution is correct
> but might not perform well (you might want to enforce an ordering 
> constraint without waiting, for example for the first buffer of an LFS
> segment) but some people have suggested to me in the past that it
> doesn't actually preserve the old FFS metadata ordering semantics.  I
> don't see why not -- and, actually, I can't see a whole lot of examples
> where it's not just as good as adding B_ORDERED, and a lot less work.  
> Can someone give me an example of where it either doesn't work or doesn't 
> work as well as B_ORDERED would?

I believe we're in agreement here. *I* think we should add and use
B_ORDERED. If some drives are broken, they lose and get blacklisted such
that they don't do tags. While I respect Leonard's work for the BusLogic
driver, I think that drivers, and in particular HBA drivers, should not be
the ones to set tag ordering policy. If things are broken, there are
acceptable workarounds. If people don't like the workarounds as being too
restrictive, they're welcome to turn things back to SIMPLE tags as they
like.

A slight point of implementation here- it is my belief that the HBA driver
shouldn't see B_ORDERED- it should be up to the specific target driver to
turn B_ORDERED or what have you into the tag that is appropriate- that is
policy. The HBA driver then will implement this policy. I believe that
Jason mentioned to me he was working on some midlayer tag stuff for
NetBSD- I hope that this then becomes tag management subroutines that
some HBA drivers that need to do manual tag management can use, while
other HBA drivers which have f/w that does the tag management for them.

-matt