Re: Plan: journalling fixes for WAPBL

[Thor Lancelot Simon <tls%panix.com@localhost>]

On Mon, Jan 02, 2017 at 06:08:04PM +0000, David Holland wrote:
> On Mon, Jan 02, 2017 at 01:01:34PM -0500, Thor Lancelot Simon wrote:
>  > On Mon, Jan 02, 2017 at 05:31:23PM +0000, David Holland wrote:
>  > > (from a while back)
>  > > 
>  > > However, I'm missing something. The I/O queue depths that you need to
>  > > get peak write performance from SSDs are larger than 31, and the test
>  > > labs appear to have been able to do this with SATA-attached SSDs...
>  > > what are/were they doing?
>  > 
>  > Aggressive prefetching, extreme efforts to reduce command latency at
>  > the drive end of the SATA link (and higher link speeds), plus much
>  > larger request sizes than we can issue.
> 
> Yes, but I mean testing with queue depths > 31, like ~100, which I'm
> sure I remember seeing. But maybe I'm wrong... obviously I should go
> rake up some links, maybe later.

The tests could have been run with RAID controllers that present a
SCSI interface to the host.  These often support very deep queues both
for the virtual targets and at the adapter (channel) itself, at which
point it's all about minimizing latency again on the controller's side
of the interaction, where it really _is_ SATA with a limited queue
depth.

If you want a large number of SATA targets in one box you are likely
using a RAID controller even if you're just using it in JBOD mode.  That
makes every SATA target look like a SCSI target.

Thor