<div dir="ltr">responses inline<div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, Aug 16, 2013 at 9:41 AM,  <span dir="ltr"><<a href="mailto:steve@linuxsuite.org" target="_blank">steve@linuxsuite.org</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">> We're seeing something similar on the same gear (LSI/supermicro expanders,<br>
> lsi controllers, sata drives).<br>
><br>
> We've tried standard hardware debugging (cable reseat/replacement, etc)<br>
> and<br>
> the problem in our case seems to follow the sas expander backplane.<br>
><br>
> We did a disk by disk migration into a different expander and they<br>
> stopped.<br>
><br>
> How high are your error counts? (in our case, we were getting about<br>
> 1500/day/device). Is your performance impacted? (it was in our case)<br>
>  -nld<br>
><br>
<br>
</div>        Different expander? but still SATA behind SAS expander? On<br>
Supermicro 847 chassis?<br></blockquote><div> </div><div>Same model of expander, still SATA behind a SAS expander. Still supermicro 847. </div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

        Is your setup stable, ie. works and drives don't drop out as failed?<br>
Performance isn't an issue here, but stability is..<br></blockquote><div><br></div><div>We're having extreme performance issues, but no stability problems. The system just does I/O slowly. (less than 50MB/s, when we should be getting 1-2 GB/s for scrubs, etc)</div>
<div><br></div><div>Moving the drives to another expander resolved the issue, though we had a second expander start experiencing the same issues at a lower rate, so we have more drive moves to do before we can expect to resolve the lower rate errors. </div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
         It is definately a SATA behind SAS expanders issue. I did lots of<br>
testing<br>
with pools built on SAS drives they have no errors.  I also did a lot of<br>
stress testing<br>
with 20T SATA pools, they were completely unusable, scrub would<br>
always wipe out the pool because drives would "drop out" as failed,<br>
but a hardware power cycle of the  SuperMicro chassis<br>
would bring them all back. Then I turned off NCQ on the  LSI controller<br>
and everything worked fine. Couldn't get anything to fail no matter<br>
how hard I beat on it.<br></blockquote><div><br></div><div>We haven't had any issues like this at all. We've got at least 8 of these kinds of systems, with similar configs (SATA drives, SAS expanders, generally not chaining expanders). Each of them has at least 80 spindles, and generally they work reliably and perform well. (Excluding cases where there is a bad drive in a stripe, etc) Getting upwards of 2GB/s in aggregate off of one of these isn't hard.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
         I will start to track error rates, we are not moving much data yet..<br>
<br>
         Would SATA port multipliers be a better solution? Does<br>
Solaris/OmniOS<br>
support such a hardware config.<br>
<br>
           Just came across this<br>
<br>
             <a href="http://www.45drives.com/" target="_blank">http://www.45drives.com/</a><br>
<br>
         Which I think is  a SATA port multiplier solution....<br>
Centos/NetBSD?? can<br>
it work with OMniOS?<br></blockquote><div><br></div><div>I'd assume it would work as long as there is a driver for those sata controllers, but you know what they say about assuming. These seem a bit expensive, particularly considering they don't include any drives. </div>
<div> -nld</div></div></div></div>