[oi-dev] SSD-based pools

[Andrew M. Hettinger]

"Schweiss, Chip" <chip at innovates.com> wrote on 09/28/2014 10:07:15 AM:
>
> On 26/09/2014 00:46, Andrew M. Hettinger wrote:
>> I'm presently running tests on a pool using 3x Samsung 850 SSDs on a
>> LSI-9211-8i
>> (IT) contoller. I thought I'd try seperating the intent log to see if
lowering
>> the write amplification on the pool-drives would help, so I added
another
>> matching SSD for that, but under load I still seem to get extensive
checksum
>> errors. Does anyone have any ideas as to what would be causing this?

>
> I would suspect hardware.   Avoid overly cheap SAS cables.

I'll try it in another machine as soon as I can, but it seems to work fine
with spinning HDs.

>
> I run nearly 100 SSDs with Illumos based ZFS.  63 of them are
> Samsung 840 Pros in a pure SSD pool in a Supermicro JBOD.   I don't
> see any checksum problems.

> The 850 has the same firmware as the 840 so the new generation
> should not make any difference.
>
> I also always run SAS to SATA interposers to keep the SAS buses
> happy.    However, Samsung SSDs are the only brand SSD that I found
> to consistently work with the interposers.

Can you link me to the interposers? I wonder if that would make a
difference.

>
> All my HBAs are LSI 2308 and 2008 controller based.   Make sure your
> firmware is up to date.  There have been many SSD related fixes in
> the LSI HBA.

Firmware is current. I checked LSI's site last week.

> If you can avoid it don't use a SAS expander, they will slow things
> down and without interposers are susceptible to reset storms.

There is no SAS expanders involved.

> A log device is really necessary on an SSD pool.   The sync write
> behavior of ZFS simply does not work well with SSDs with out a log.
>   Using an 850 is not a good choice for a log device because it does
> not have power loss protections. You are better off turning sync off
> than trying to use them as a log.

Can you make a recommendation for the slog?

>
> -Chip

Thanks for everyone's help here!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://openindiana.org/pipermail/oi-dev/attachments/20140929/7d482cee/attachment-0005.html>