[email protected] said:
> The delay should be on the order of 500ms. The turn around time for
> re-issuing the command is not a sufficient delay.
That's not what the spec says. It just says "reissue at a later time".
SCSI-2 also implies BUSY is fairly interchangeable with QUEUE FULL. SAM-3
clarifies that BUSY should only be returned if the target doesn't have any
pending tasks for the initiator, otherwise TASK SET BUSY (renamed QUEUE FULL)
should be returned.
Half a second's delay on BUSY would kill performance for any SCSI-2 device
using this return instead of QUEUE FULL.
It sounds more like an individual device problem which could be handled in an
exception table. What device is this and why does it require 0.5s backoff?
> Do you run all of your devices with a queue algorithm modifier of 0?
> If not, then there certainly are guarantees on "effective ordering"
> even in the simple queue task case. For example, writes ands reads to
> the same location must never occur out of order from the viewpoint of
> the initiator - a sync cache command will only flush the commands that
> have occurred before it, etc, etc.
I run with the defaults (which are algorithm 0, Qerr 0). However, what the
drive thinks it's doing is not relevant to this discussion. The question is
"does the OS have any ordering expectations?". The answer for Linux currently
is "no". In future, it may be "yes" and this whole area will have to be
revisited, but for now it is "no" and no benefit is gained from being careful
to preserve the ordering.
> I've already written one OpenSource SCSI mid-layer, given
> presentations on how to fix the Linux mid-layer, and try to discuss
> these issues with Linux developers. I just don't have the energy to
> go implement a real solution for Linux only to have it thrown away.
> Life's too short. 8-)
What can I say? I've always found the life of an open source developer to be a
pretty thankless, filled with bug reports, irate complaints about feature
breakage and tossed code. The worst I think is "This code looks fine now why
don't you <insert feature requiring a complete re-write of proposed code>".
I can ceratinly sympathise with anyone not wanting to work in this
environment. I just don't see it changing soon.
James
> > I've already written one OpenSource SCSI mid-layer, given
> > presentations on how to fix the Linux mid-layer, and try to discuss
> > these issues with Linux developers. I just don't have the energy to
> > go implement a real solution for Linux only to have it thrown away.
> > Life's too short. 8-)
>
> What can I say? I've always found the life of an open source developer to be a
> pretty thankless, filled with bug reports, irate complaints about feature
> breakage and tossed code. The worst I think is "This code looks fine now why
> don't you <insert feature requiring a complete re-write of proposed code>".
>
> I can ceratinly sympathise with anyone not wanting to work in this
> environment. I just don't see it changing soon.
Justin, and all of us, are quite content to work in an Open Source
environment I believe. It is the true inheritor of the original Unix
philosophies.
But it's difficult to commit to an effort that one often feels is a
waste of time from the git go. This is one of the bootstrapping problems
of the Linux environment: pretty much everyone expects you to produce a
working prototype of a problem solution *before* people will accept it-
how else can they evaluate it, hmm?
But major amounts of work would have to be expended before you would do
something like present 'CAM in linux' for review. That makes for a
natural tendency to try and assess *beforehand* whether there's even a
point in trying. I think that the subtext of Justin's comment, to put
words in his mouth which can later deny if he likes, is that there's a
sense that some of the solutions he'd propose/do would never be
accepted, so why spend an effort sure to be wasted?