Subject: Re: b_actf/b_actb -> TAILQ, plus B_ORDERED ... diffs
To: Jason Thorpe <firstname.lastname@example.org>
From: Matthew Jacob <email@example.com>
Date: 01/18/2000 15:45:32
> > 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,