IBM blade server abysmal disk write performances

Scott Long scott4long at yahoo.com
Sun Jan 20 00:11:04 UTC 2013


On Jan 19, 2013, at 4:33 PM, Wojciech Puchar <wojtek at wojtek.tensor.gdynia.pl> wrote:

>> to be enabled to get any speed-up from tagged commands. This was no
>> risk with SCSI drives, since the cache did not make the drives lye
> 
> i see no correlation between interface type and possibility of lying about command completion.
> 

Any interface that enables write cache will lie about write completions.  This
is true for SAS, SATA, SCSI, and PATA (and probably FC and iSCSI).  That's
the whole point of the write cache =-)

Where things got interesting was in the days of SCSI vs PATA.  There was
no tagged queuing for PATA, except for a hack that allowed CDROMs to
disconnect from the shared bus.  So you only got 1 command at a time, and
you payed a serialized latency penalty.  The only way to get reasonable
write performance on PATA was to enable the write cache.  Meanwhile,
SCSI had TCQ and could amortize the latency penalty to the point where
performance with TCQ and no WC was almost as good at with WC.  This
made SCSI the clear choice for performance + data safety.

With SATA vs SAS, the gap is much narrower.  The TCQ command set
(still used by SAS) is still better than the NCQ command set, but the
differences are minor enough that it doesn't matter for most applications.

Scott



More information about the freebsd-hackers mailing list