>  > If you use a B_ORDERED and assume this is for devices that can do I/O
>  > re-ordering, why use disksort at all?
>  > 
>  > Mind you, I think I'm totally fine with what you're suggesting in adding a
>  > B_ORDERED flag, but it defeats the purpose of having devices which can do
>  > their own sorting if you call disksort and spend time sorting for them. In
>  > fact, it can make things a lot worse.
> 
> I'm getting to that :-)  This is a first step.  Note that drivers have
> the option of calling disksort() or not.  However, in the case of e.g.
> floppies (we certainly don't want those to get any *slower*) or older
> disks for which disksort() will be beneficial.  Also, for ZBR disks
> without tagged queueing, a simple sort based purely on block number
> could be beneficial, as the disk will see it as "sequential writes".
> 
> After tossing some ideas around w/ Mycroft, we figured a pointer to
> a sort function in a disk's "struct disk" would work.  You'd have
> a few options:
> 
> 	- cylinder/block elevator sort (what we have now)
> 	- block-only sort which generates forward-only sequential writes
> 	  (like FreeBSD's bufqdisksort())
> 	- insert-at-end-of-queue
> 
> In all cases, B_ORDERED implements the barrier.
> 
> B_ORDERED is intended to be an abstract way of specifying the barrier,
> for the benefit of file systems, which otherwise couldn't care less if
> the disk supports ordered queue tags, is an SMD on Xylogics 753 (which has
> its own on-controller sorting stuff),

(a broken one, IIRC)

>or an old Massbus disk (for which the
> elevator sort is quite useful).

No objections on this.


> 
> Also, from a discussion I had w/ Christoph Badura, it could be useful
> to experiment w/ the latter two queueing schemes above on different
> ordered-tag-capable disks.

Yes. It all sounds good to me, you've thought it through, I'll go away now,
thanks...