> At 09:54 AM 9/27/99 , Thor Lancelot Simon wrote:
> 
> >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).
> 
> FWIW, the DEC RZ25L had a problem with tags such if enough I/O happened,
> some tagged requests would be seriously delayed.  The drive was trying
> to optimize access and travel and if a I/O went to an idle part of the
> disk, it might never get serviced.  Digital eventually released an 
> update for the firmware to correct this problem.

Yup- that's pretty standard. I've bitched at Bob Snively (Sun's rep to the
ANSI SCSI committee) for years about the inability to require anything of
target task management other than 'ABORT'- if the Nth tagged command seems
to not have completed after some 'reasonable' interval, the only thing you
can do is abort it- you can't reprioritize it or even ask the target
what's up (like, "You still alive? Let's kill you to find out...Yup, you
*were* still alive, but you're dead now..."). There have been some
additions very recently to the T10 working group's set of specs for task
management that may address this, but we'll see (IIRC somebody, I forget
who, complained that one needed PHd to follow the new task management
specs)...

At any rate, it still seems desirable to architect for what it ought to be
and provide workarounds to h/w bugs - with a varying amount of pain so
that some kind of feedback to the target f/w folks provides incentives for
doing the right thing....

-matt