[OmniOS-discuss] How bad are these controller / io errors??

[Valrhona]

I have a Dell tower server with a 16-bay 2.5" SAS hotswap backplane. I
have been using small SAS drives (36 GB) for the mirrored rootpool,
but these are tending to fail (because they are so old). I tried one
of the Intel SLC 20 GB SSD drives (311), and that seemed to work in
the backplane (some other SATA drives screwed up everything, so I
pulled them out). No harm done in testing, but is this a bad idea in
general? Will this screw up the rest of the SAS drives in the same
8-drive channel?

I would love to get a slow, small (<32 GB) SAS SSD for the rpool, but
no one seems to sell one. Just needs to be reliable, and with the
rpool being overwhelmingly read-dominated, this doesn's seem too hard.
Even Intel's "enterprise" SSDs (DC3500, 3700) are SATA, not SAS. And
obviously it's silly to spend $300+ each on two 100 GB SAS drives from
Seagate (the cheapest i could find). I don't want to run off of USB
sticks, either, for reliability reasons.

Any ideas? Thanks!

Peter

On Mon, Aug 19, 2013 at 9:33 PM, Garrett D'Amore
<garrett.damore at dey-sys.com> wrote:
> SATA drives behind SAS expanders have a pathological error case.  If a drive encounters errors and it needs to be reset then the entire set of drives will take the reset.  If any io is in flight this will error as a result often causing another reset.  The result can best be described as a cascade failure.
>
> There may be things software can do to mitigate this but experience is that it doesn't.
>
> So just because the array is working fine now does not mean that it won't fail tragically when the first problems occur.
>
> I have personal experience with this failure mode.
>
> As a result I strongly discourage the use of SATA drives unless they are directly connected to the hba without any expanders or port multipliers.
>
> You ignore this advice at your own risk.  Don't penny pinch on the drives   It ALWAYS costs you in the long run.
>
> Sent from my iPhone
>
> On Aug 19, 2013, at 4:25 PM, steve at linuxsuite.org wrote:
>
>>> Can't agree more here. Desktop firmwares are designed to try harder to
>>> never return an error.  While this is what home users want, it's an
>>> anathema to large configurations with redundancy where you would prefer to
>>> just get the error so you can handle it - usually by doing the op on
>>> another drive.
>>>
>>> Use enterprise drives if you love your data and your ability to access it.
>>
>>        Yes I know, I know....  Desktop hardware sucks. Didn't know there was
>> Enterprise (ie none Desktop) SATA. Perhaps the solution is to  partition
>> the data and do "deep" storage that never gets read on large bulk SATA and
>> then have a smaller SAS pool for the often read/written stuff.
>>
>>      Anyway, large storage rollouts will always be looking for
>> the cheapest solution. Even if it isn't perfect. I do backups
>> to a SATA pool (behind SAS expanders) with zfs send,.. no problems errors
>> whatever YET!!
>> (cross fingers)
>>
>>       -steve
>>
>>>
>>> Sent from my iPhone
>>>
>>> On Aug 19, 2013, at 2:47 PM, Eric Sproul <esproul at omniti.com> wrote:
>>>
>>>> On Mon, Aug 19, 2013 at 5:35 PM,  <steve at linuxsuite.org> wrote:
>>>>>    4T SATA  here
>>>>>
>>>>> http://www.newegg.com/Product/Product.aspx?Item=N82E16822178338
>>>>>
>>>>>         are $179
>>>>
>>>> That's a desktop drive, not nearline enterprise, so it's
>>>> apples-oranges.  You get what you pay for.  Desktop drives can take
>>>> much, much longer to respond to commands, leading the HBA/expander to
>>>> declare them dead and reset them, and the rest is history.
>>>>
>>>> Avoid desktop parts.  :)
>>>>
>>>> Eric
>>>> _______________________________________________
>>>> OmniOS-discuss mailing list
>>>> OmniOS-discuss at lists.omniti.com
>>>> http://lists.omniti.com/mailman/listinfo/omnios-discuss
>>
>> _______________________________________________
>> OmniOS-discuss mailing list
>> OmniOS-discuss at lists.omniti.com
>> http://lists.omniti.com/mailman/listinfo/omnios-discuss
> _______________________________________________
> OmniOS-discuss mailing list
> OmniOS-discuss at lists.omniti.com
> http://lists.omniti.com/mailman/listinfo/omnios-discuss