On Oct 8, 2012, at 2:07 PM, Roel_D <[email protected]> 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 <[email protected]> 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 >>> [email protected] >>> http://openindiana.org/mailman/listinfo/openindiana-discuss >> >> -- >> Vennlige hilsener / Best regards >> >> roy >> -- >> Roy Sigurd Karlsbakk >> (+47) 98013356 >> [email protected] >> 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 >> [email protected] >> http://openindiana.org/mailman/listinfo/openindiana-discuss > > _______________________________________________ > OpenIndiana-discuss mailing list > [email protected] > http://openindiana.org/mailman/listinfo/openindiana-discuss -- [email protected] +1-760-896-4422 _______________________________________________ OpenIndiana-discuss mailing list [email protected] http://openindiana.org/mailman/listinfo/openindiana-discuss
