Re: SATA vs SAS drives for RAID (Threaded from Thoughts on VTL solutions)

Sorry I oversimplified. I answered only the question at hand.

Those many solutions on the marked using SATA drives often do appear to lock up when they don't get a response from a dead drive. Also they may be doing mirroring or software RAID where additional control can be available.

And mostly they do SATA because it's cheaper, bottom line.

- Larry "DrFranken" Bolhuis

www.Frankeni.com
www.iDevCloud.com - Personal Development IBM i timeshare service.
www.iInTheCloud.com - Commercial IBM i Cloud Hosting.

On 5/9/2020 12:29 PM, Patrik Schindler wrote:

Hello Larry,

Am 09.05.2020 um 17:03 schrieb DrFranken <midrange@xxxxxxxxxxxx>:

SATA is designed for PCs. As such if there is an error it tries again.

Please explain why there are numerous NAS solutions on the market, utilizing SATA drives.

This behaviour is *not* the (main) difference between SAS and SATA. It's also about power saving vs. performance. It's about better command queueing and reordering of requests. It's about optional being dual-ported for redundancy or performance reasons. It's about faster chips on the drive logic board to handle more IOPs over bus to local cache. It's *maybe* about the ruggedness of mechanical parts to not wear out with 100% seek activity over extended periods of time. And… see below.

Seems like a good idea and often given sufficient retries the drive will actually return data. When that's your data it's good news! With PCs they rarely have data protection so there is really little other choice and it boils down to 'get my data or I'm in deep weeds!'

This is a somewhat oversimplified explanation of the real issue. Drives in fault tolerant RAID levels are supposed to report failure more early. If they don't, the whole RAID volume stalls until the drive reports back about if the request was successful or not. So, failing early keeps this stalling to be short. Better kick the disk out of the RAID, because one failed disk is not catastrophic. But the RAID volume is still working without forcing higher level functions in the whole software stack to run into timeouts.

The SCSI standard defines drive internal parameter pages to control caching, error recovery, automatic shutdown, data prefetching, some tweaks to how to handle certain SCSI commands, etc. These can be changed by software and are saved permanent to the drive's media. This is also true for SATA drives.

Side note: As it works out virtually all SAS controllers can also control SATA drives since the capabilities of SATA are a subset of SAS.

True. The most distinct factor is that SATA does *not* define a point to multipoint infrastructure. There is no "SATA expander" for having many drives to a single interface. SATA needs a direct point to point link from disk to chipset handling the communications.

Putting SATA drives into SAS enclosures with SAS expanders *might* work because SAS defines a SAS encapsulation protocol for driving SATA disks in a SAS environment. My experience with different enclosures from HP(E) shows that the resulting performance is poor, because the expander chips have to handle the encapsulation protocol.

:wq! PoC

PGP-Key: DDD3 4ABF 6413 38DE - https://www.pocnet.net/poc-key.asc