On Jan 31,  3:34pm, proprietor - Foo Bar And Grill wrote:
} Subject: Re: NCR Driver Problems
}  * 
}  * In general, using queue tagging can only help performance (unless
}  * you're doing something dumb like trying to use too many tags; the
}  * number of tags supported is a drive-dependent value).  If you consider
}  * the worst case of a drive's handling of tagged commands, it will
}  * process them in the order received.  That's equivalent to sending them
}  * down one at a time.  (OK, actually, if you send them down one at a
}  * time, the extra delay in sending them to the drive may get you some
}  * disksort() wins, but it's not clear that it would really help.)  In
}  * the best case, the drive can optimize the handling of the requests so
}  * that they're handled in the 'best' order.
}  * 
} 
} So, in other words, disksort() is now obsolete and should be replaced.

If the drive you're talking to only has a single actuator, then you still
want to preprocess the queue with disksort() so that all the commands
sent to the drive are for sectors that are close together.  The drive
can then do the final optimization based on it's real time head and
rotational position status.

Disksort() will also help performance on a RAID, but it would be even
better if the OS was aware of the RAID sector mapping.  It could then
sort requests separately for each drive in the array.  This is gets
messy in the presence of parity drives and commands that want to access
more than one drive.

} Are there any drives newer than, say, two years old which don't handle
} tagging?

Since this isn't a heavily used feature, there are a lot of drives that
have bugs in their tagged command handling.  Solaris 2.x uses tagged
commands by default, and much of the time the advice given about SCSI
problems says to disable tagged commands.

			---  Truck