[OpenIndiana-discuss] Raid type selection for large # of ssds

Richard Elling richard.elling at richardelling.com
Tue Oct 9 00:52:09 UTC 2012


On Oct 8, 2012, at 2:07 PM, Roel_D <openindiana at out-side.nl> wrote:

> I still think this whole discussion is like renting a 40 meter long truck to move your garden hose. 
> 
> We all know that it is possible to rent such a truck but nobody tries to role up the hose.... 
> 
> SSD's are good for fast reads and occasional writes. So don't use them for datastorage of fast changing data. 

This is not a true statement. There are variety of SSDs that have been used for high
transaction rate systems for a long time, eg RAMSAN. Other new entrants are well 
designed for high transaction rates (FusionIO, Violin) Not all SSDs are created equal 
and you need to choose the best one to fit your needs.
 -- richard

> 
> Put the OS's on an SSD raid construction and the rest on a SAS platter RAID construction. 
> 
> Kind regards, 
> 
> The out-side
> 
> Op 8 okt. 2012 om 21:26 heeft Roy Sigurd Karlsbakk <roy at karlsbakk.net> het volgende geschreven:
> 
>> An SLC SSD would probably be substansially slower than an array of MLC SSDs, and would be likely to slow down the system for sync writes.
>> 
>> ----- Opprinnelig melding -----
>>> Hi,
>>> from what I understood from negative experience with a 12-drive SSD
>>> RAID
>>> set build with MDRaid on linux, and from answers to a related question
>>> I
>>> raised recently in this list, it is not so easy to engineer a
>>> configuration using a large count of SSDs anyhow. The budget option,
>>> using SATA SSDs, seems to be critical in some terms. Using an SSD type
>>> based on a controller using compression seems to be a suboptimal
>>> choice
>>> for any data that will not compress efficiently (which is more likely
>>> writing as a stripe set (RaidZn)). Other concern seems to be SATA vs
>>> SAS
>>> in general, and compatibility of SATA SSDs with the usual SAS HBAs and
>>> -
>>> Extenders.
>>> One should be aware that any of these aspects is prone to make the
>>> vdev
>>> unresponsible, or even kick drives out of the vdev. Should that be a
>>> systematic issue, the stripe set will not rebuild properly or even be
>>> lost in an instant, with no parity level offering protection.
>>> 
>>> Another option could be to look into a setup that is using a SLC or
>>> RAM-based ZIL device, and/or a large SSD based L2ARC. That's what I am
>>> looking into, currently.
>>> 
>>> BR
>>> 
>>> Sebastian
>>> 
>>> _______________________________________________
>>> OpenIndiana-discuss mailing list
>>> OpenIndiana-discuss at openindiana.org
>>> http://openindiana.org/mailman/listinfo/openindiana-discuss
>> 
>> -- 
>> Vennlige hilsener / Best regards
>> 
>> roy
>> --
>> Roy Sigurd Karlsbakk
>> (+47) 98013356
>> roy at karlsbakk.net
>> http://blogg.karlsbakk.net/
>> GPG Public key: http://karlsbakk.net/roysigurdkarlsbakk.pubkey.txt
>> --
>> I all pedagogikk er det essensielt at pensum presenteres intelligibelt. Det er et elementært imperativ for alle pedagoger å unngå eksessiv anvendelse av idiomer med xenotyp etymologi. I de fleste tilfeller eksisterer adekvate og relevante synonymer på norsk.
>> 
>> _______________________________________________
>> OpenIndiana-discuss mailing list
>> OpenIndiana-discuss at openindiana.org
>> http://openindiana.org/mailman/listinfo/openindiana-discuss
> 
> _______________________________________________
> OpenIndiana-discuss mailing list
> OpenIndiana-discuss at openindiana.org
> http://openindiana.org/mailman/listinfo/openindiana-discuss

--

Richard.Elling at RichardElling.com
+1-760-896-4422





More information about the OpenIndiana-discuss mailing list