This is a late answer, but I would like to add my opinion.
From a pure speed standpoint, a nearline drive (as the ones OP considered) will performs practically the same both using the SATA interface or SAS interface. Despite the much lower-depth NCQ (31 entries rather than TCQ 64K), this limited hardware queue is sufficient, when augmented with the much deeper software-based IO queue, to extract almost the same IOPS which can be obtained using SAS-based TCQ.
Anyway, this does not means that SAS has no practical advantages:
- much better support for expanders
- support for double-link interface
- full-duplex operation
- much faster maximum signaling rate (12 Gb/s vs 6 Gb/s)
However, when considering performance alone, the sad reality is that mechanical disk's random IOPS values are so low that the interface has almost no impact, excluding huge disk arrays where is can sometime limit your sequential IO transfer rate. Due to how they take rotational delay (which is hidden from the OS) into account, the killer performance-enhancing feature is NCQ/TCQ, and the SATA implementation is sufficiently good at that.
Some more significant differences appear when considering higher end SAS disks, which not only offer higher-RPM disks (10K and 15K), but have some interesting write-coalescing technologies (ie: HGST media cache tech) which, by the way, are slowly spilling into enterprise-SATA drives also.
However, the ATA standard has a design flaw. The NCQ tag is presumed
to be a 32-bit bitmap (32-bit dword). If all 32 tags are asserted,
this produces a value (0xffffffff) that is the same value returned by
reading a hardware register after the hardware has been hot-unplugged,
or suffers a major failure. Thus, to distinguish this condition,
libata artificially limits all NCQ configurations to 31 tags rather