> The number of commands that can be usefully outstanding per nexus (i/t/l)
> is determined by knowledge gathered per SCSI bus (tags outstanding for the
> target/lun side, HBA transport resources known by the HBA), but the
Ok
> number of commands that can be usefully and correctly set outstanding per
> system is known by the system- not one HBA (amount of I/O mapping
> resources still available for systems that need this, proper scheduling of
> multiple busses, etc.).
Yes
> In short, correct scheduling policy is set by the overall system with
> per-bus information being only one factor in the equation.
yes - you need information from both. But at that point I don't buy your
argument. The HBA can check resource status just as well as the midlayer
can ask the HBA. Furthermore if the HBA wants to do something wacko for
good reasons (eg if it has hidden private resources) it can do so if
its in charge. So the HBA has to be able to consult the midlayer and
set policy to reflect HBA variances.
We have 50 HBA's one midlevel, so HBA's can handle midlevel hints more
easily that the midlevel having to be tuned for 50 conflicting requirements
> It's possible that the overall ll_rw_blk function could do this job, but
> in order to do it right, it would have to take on all of the factors
> listed above rather than the current demand driven model.
ll_rw_blk already does merging in 2.3.x
> Error Recovery/Long term example:
>
> I have a multipath arrangement with two Fibre Channel busses. One card
> gets kicked off the loop (cable breaks, whatever). The queue for that card
> is blocked while it tries to get back on the loop. A reasonable overall
> scheduler would shift the I/O to the alternate path.
>
> [ this is a bit of a stretch- hrmm, maybe error recovery is less of a
> whole system property in the more common cases ]
With i2o this one comes up quite easily. It also comes up outside of scsi,
so its an ll_rw_blk or raid issue
Imagine adding a raid mode for ghost disks. Any will do for read or write,
including balancing strategy if appropriate (which I doubt), retry on error
to another ghost.
Alan
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to [EMAIL PROTECTED]
