Nexenta had some "issue" reports relating to the mpt driver. In almost all cases, the results are related to situations where people are using SATA drives, and hooking them into SAS configurations.
Although the technology is supposed to work, and sometimes it works well, its a bad idea.
- SAS drives are generally subjected to more rigorous quality controls. This is the main reason why they cost more. (That and the market will pay more.)
- SAS to SATA conversion technologies involve a significant level of protocol conversion. While the electricals may be the same, the protocols are quite different.
- Such conversion technology is generally done in hardware, where only the hardware manufacturer has a chance of debugging problems when they occur.
- Some of these hardware implementations remove debugging information that would be present in the SATA packet, and just supply "generic" undebuggable data in the SCSI (SAS) error return.
- The conversion technology creates another potential point of failure.
- SATA is single ported and SAS is dual ported, so if you want to use SATA drives in a High Available, multipathed system, you need something to translate between a single port and dual port, a so called "interposer". Interposers are very sensitive to errors and interference
- Nexenta has verified that SAS/SATA expanders combined with high loads of ZFS activity have proven conclusively to be highly toxic.
- Some of these hardware implementations won't be upgradeable, or at least not easily upgradeable, with software.
- SATA drives won't have a SCSI GUID (ATA specs don't require it), and so the fabricated GUID (created by the SAS converter) may be different when you move the drive to a different chassis, potentially breaking things that rely on having a stable GUID for the drive.
SATA drives are great when you need low cost storage, and when you are connecting to a system that is purely SATA (such as to an AHCI controller), there is no reason to be concerned. But if you're designing an enterprise storage solution, please consider using SAS all the way to the disk drives, and just skip those cheaper SATA options. You may think SATA looks like a bargain, but when your array goes offline during ZFS scrub or resilver operations because the expander is choking on cache sync commands, you'll really wish you had spent the extra cash up front.
Building a system that relies upon complex protocol conversion in hardware, just adds another level of complexity. And complexity is evil. (KISS). Nexenta advises strongly to spring for the extra cost of drives that are natively SAS. Goofing around with the hybrid SAS/SATA options is just penny wise, and pound foolish. Everything is standardized on SAS. So would you rather have SAS all the way to the disk or SAS all the way and then a have a translation on the SATA disk?
And effectively SATA and SAS have the same price because if you use SATA on an enterprise storage system, you need interposers which have a cost price as well
SATA$ + Interposer$ = SAS$