up vote 1 down vote favorite
2
share [g+] share [fb]

SSD do give a really fast Random Read Performance over conventional Hard Disks typical data transfer size is 4k or 8k.
Although the Sequential Reads performance is not that huge, data transfer size of 128k or 64k sequentially.
But when it comes to writing to disks, enterprise storage arrays (EMC DMX4, HDS USPv etc) writes all data to cache and the write is acknowledged to the host. Destaging takes place later.
In such a scenario, how is SSD going to perform?
Moreover, for updates in oracle the ssd have to go through the erase-write cycle, conventional hdd dont. How does this impact performance?

link|improve this question
2  
Are you just going to carry on clogging up this site with these generalised, homework-style 'what if?' style questions with nothing ever too specific? they're bad fits for this site, it's about questions and answers, not vague notions and heavily caveated opinion. Look around and see the kind of questions other people are asking and take that into account otherwise you'll be suspended or deleted. – Chopper3 Aug 25 '11 at 12:32
Any mid-grade or better HBA is going to have write-back caching too. It is not the exclusive domain of Storage Arrays. Further, those caches have a finite size; they'll fill if you write enough data all at once, then you'll be back to write-through performance. TRIM was invented specifically to deal with the erase-write cycle, read up. – Chris S♦ Aug 25 '11 at 12:47
TRIM is a command NOT supported by all operating systems (implementation of TRIM vary by os). Moreover, TRIM does NOT work with RAID created on the SSD. My question is- How Do I determine the degree of degradation in performance of an SSD over time? Is there a tool/utility to do this? – Jack Aug 25 '11 at 17:25
That depends on the OS and how it was created - TRIM can do exactly as Chris suggests, just not all the time or by default. – Chopper3 Aug 25 '11 at 17:27
feedback

closed as not a real question by ErikA, Shane Madden, Ward, Chopper3 Aug 25 '11 at 17:27

It's difficult to tell what is being asked here. This question is ambiguous, vague, incomplete, overly broad, or rhetorical and cannot be reasonably answered in its current form. See the FAQ for guidance on how to improve it.

1 Answer

up vote 0 down vote

The NVRAM/cache of the storage array has complex caching algorithms, where not only a watermarking system (high + low) is employed but also certain timing parameters come into play so that ie the NVRAM is flushed every few seconds etc.

Usually the array cache size is much smaller than the total storage capacity of the whole system. The SSDs come into play when your access pattern (read and writes) are really randomly spread out over a big portion of that array and the ingress IO flow is high the NVRAM/cache just helps for the first IO bursts then you'll still only get the combined IO performance (depending on RAID group properties and RAID mode etc.) of your rotating rust or the SSDs if you employ these.

Depending on the storage array it internally might use SSD to additionally cache reads or writes as the SSD cache is much bigger and much slower and also easier to implement than DRAM cache since the SSDs are usually part of the FC or SAS fabric and seen by all controllers. Normal NVRAM/wirte cache might also need a cache coherent synchronization etc.

EMC et al make a big secret as to what they're actually doing when SSDs are attached and usually it's not your run-of-the-mill MLC SSDs - I'm talking about enterprise grade SSDs (in terms of $$$) that might be hybrid-DRAM (STEC) or FusionIO-like designs which work quite different to the stuff you read on the net about SSDs.

link|improve this answer
feedback

Not the answer you're looking for? Browse other questions tagged or ask your own question.