SSD Write Endurance 25nm Vs 34nm

[groberts101]

SF drives cannot sustain performance levels without burning up the NAND, despite the compression advantage, hence the drives are life time throttled. LOL.. you've been swallowing the propoganda that Tony has been feeding over at OCZ fourms haven't you? Hook.. line.. and sinker. Do you actually seriously believe that compression provides absolutley no additional lifespan increases?

Intel drives provide consistent write speeds throughout the life of the product and regardless of xfer size. SF drives can't do this. Then you obviously haven't tried a secure erase to wipe Durwrite's mapping requirement to keep it actively implemented.

Yes you might get short term performance boosts before throttling kicks in, but once it has kicked in you are stuffed. Takes me all of 10 minutes(no bull) to SE/reimage all 6 of my drives and be back to "un-stuffed" full speed states. They should call it "map-life throttle".. NOT.. "life-time throttle" since an SE wipes the map quite easily and therefore eliminates any throttling altogether until the map is fully reformed when all space has been written at least once. This is where capacity is worth it's weight in gold for a Sandforce controlled drive.

Another thing to consider is the lack of throttling and ability of the newer SF2281 controllers to lift throttles MUCH more quickly than the first gen 1xxx series controller. If the above assumptions are true than they just killed the lifespan of these drives by cutting back on the throttling on these new controllers. Then it also begs the question of how/why would they do that(adjust throttling) especially considering they just cut PE/c from the original 34nm/5000k to 25nm/3000k on the new drives?

I've said it many times already.. they simply used the "lifetime throttle to promote lifespan" crap for a smokescreen as to hide the weakness/limitation of the original recycling engines performance on the first gen SF controllers. I also said that if SF could have made the drive avoid/limit throttles on the first gens?.. many mfgrs would have jockeyed for sales dominance by making custom firmware adjustments to one-up the other guys(even possibly reducing warranties on specialized EXTREME models to do it). Never happened because that's all the drive could effectively maintain once it was completely dirty and doing things on the fly(read-write-modify). Recycling engine was too small to make it sustainable, is all. New recycling engine is larger and much improved(TRIM marked blocks are also more effectively/immediately used I suspect) which is why throttling is able to be modified nowadays.

So,.. the new one's throttling was adjusted... because?.. it could be. Simple as that.

Have to read through all the advertising and bulls*it to really piece these things together sometimes. Lifetime throttles are just a big smokescreen to lead those away from the limitations of the first gen drives and it surely worked on most people who asked the question. I also HIGHLY doubt that "too many SE's/Durawrite map bypassing" will kill these drives prematurley as well. Not that I beleive smart data on these drives any further than I can throw it.. but mine actually appear to be in better shape than most of the "just use it throttled" users out there. With 5TB written to EACH 1 of my 6 drives?.. they are not even showing any reallocation counts yet. But with more than 100 SE's on each of my drives now.. who knows?.. maybe I'll trash the charge pumps on my drives and eventually be unable to SE anymore. Hardly think it will matter by that point though as I will have upgraded 2 times over by then and they will be overpriced USB storage solutions or sitting in the kids game machine/netbook. Time will tell the true story.

After all that.. I just want to say that I really appreciate these guys "taking one for the team" by doing this write endurance testing. Much appreciated and you can't be thanked enough for doing it. Anxious to see how far beyond rated PE/c we can go here. Even makes me wonder if you guys can sustain the time and willpower to stay on course if they continue on for too long after 0% lifespans are hit. Will the counters just reset again? Again with the.. "screw SMART and only time will tell". lol

[Ao1]

If a SF drive is throttled or not depends on the settings the vendor selects. That is equally true for the SF-2281.

According to Mushkin:

"DuraClass management functionality is still active. “Unthrottled” in this context refers to write IOPS bursting up to 90,000+ but being governed down to 20,000 after a few seconds which is typical behavior with standard firmware with SF-2281. The firmware we have on the Chronos and Chronos Deluxe drives will not have that governor activated."

Excluding the burst speed throttling there is also a different type of throttling implementation that brings the drive to its knees if you write "excessively" for a sustained period.

The only way of alleviating that is idle time, which is completely retarded, as it has no relevance to the date on the receipt.

SE will not clear this. That data is held in a secure area of the drive. You can SE your drive once or a hundred times. It won't clear it.

I would suggest that if you are able to restore performance via a SE the drive was most likely in a degraded (not throttled) state.

[Ao1]

Much like Google uses consumer HDD in all of its servers, instead of enterprise SAS drives. At the end of the day, its cheaper per transaction to run the damn consumer drives.

Comp have you read this white paper that Google commisioned?

[groberts101]

If a SF drive is throttled or not depends on the settings the vendor selects. That is equally true for the SF-2281.

According to Mushkin:

"DuraClass management functionality is still active. “Unthrottled” in this context refers to write IOPS bursting up to 90,000+ but being governed down to 20,000 after a few seconds which is typical behavior with standard firmware with SF-2281. The firmware we have on the Chronos and Chronos Deluxe drives will not have that governor activated."
the term "unthrottled" in that context has only to do with short burst rates. NOT anything at all to do with sustained incompressible write speeds which is one of the only true ways to really see throttles on Sandforce controlled drives. For example.. you can test a drive with ATTO before and during throttling and the posted speeds will rarely change more than about 5%. Use incompressible data and the picture changes dramatically as the drive cannot leverage it's internal compression algorithms to falsify/fudge the numbers.

For simplicities sake.. there are 3 distinct stages to Sandforce's speeds.

1'st is "unthrottled state"/fresh speed and is maintained until a map of the entire physical space is formed(all available physical space written to at least once).

2'nd is called a "settled state" and will only write incompressible data at about 70% of its original fresh speeds(this is the "lifetime throttle" and will in fact be stopped immediately with secure erasure as the Durawrite process requires an actively mapped state of the entire physical space for it to be implemented. You can idle for days straight and this throttle will never be lifted(hence the term.. "Lifetime Throttle"). Get rid of the map with an SE?.. and Durawrite has no way of knowing that the drive should be throttled without it.

3'rd is called a "hammered state" and is implemented when the drive is written too hard and all fresh blocks have been completely depleted. At this phase of operation the controller will ony maintain about 50% of it's original fresh speeds when writing incompressible data. This is where the idle time comes into play as the controller rebuilds its fresh block reserve and que's the controller to allow the throttle to eventually lift. This is the ONLY state(although there is some grey area in here) that idle "speed recovery"(NOT talking about block recovery) is possible. And trust me here... with a 6 drive array?.. I know when I lose 110MB/s incompressible write speeds with my vid work not to mention that I immediately notice the small lags that stem from the increased latency of this algorithm(especially with heavy multitasking).


Excluding the burst speed throttling there is also a different type of throttling implementation that brings the drive to its knees if you write "excessively" for a sustained period. Yeah.. see above. Is called a "Hammered State".

The only way of alleviating that is idle time, which is completely retarded, as it has no relevance to the date on the receipt. Correct.. idle time can recover speed ONLY back to a top mark "settled state" and the lifetime throttle remains in effect.

SE will not clear this. That data is held in a secure area of the drive. You can SE your drive once or a hundred times. It won't clear it. Completely incorrect. I've purposely hammered my drives by filling them many, many times beyond capacity(once even wrote over 1TB per a single degradation test.. yeah I know.. I've heard it all before) and I know the internal algorithms/throttled stages of these drive better than most and have schooled many "experts" by now.

I would suggest that if you are able to restore performance via a SE the drive was most likely in a degraded (not throttled) state. As mentioned above there are various stages of throttles with these controllers. You can recover form ALL throttles with an SE.

Not to toot my own horn here.. BUT.. I actually tested these drives more than many others combined(conservative estimate of 10 Petabytes worth of data written for highly specific degradation/recovery testing)) and there are fully formed current maintenance protocols based on what I and others who did extensive testing found in regards to these internal algorithms. All the info was spread from the stickies/threads at OCZ forums and are now in othe mfgrs forums as well.

I know it sounds y, condescending and "know-it-all" like(I hate that too but in the end?.. I listen to the one's "in the know" as this stuff is about learning and not about pride or ego), and I don't actually really mean for it to be that way since after all.. I'm sharing here, but you would be pretty hard pressed to tell me anything about the sandforce controllers inner working that I don't already know. Is one of the main reason s that I was chosen to be a beta-tester for them.

[Vapor]

groberts101, why has the SF-1200 drive used in this endurance testing reached such a state that after moderate use (proportional to idle time) it returns to just ~7MB/s write speeds? Ao1 has done multiple secure erases and it has not helped at all.

[Ao1]

So how do I clear throttling from the V2 I used in his experiment? I have SE's numerous times and its only idling that does anything.

Also I wrote 30TB in one sitting

SF vendors should come out and make a clear statement on exactly what throttling measures have been applied and what the impact will be.
It should be a clear specification on the product.

[Anvil]

102,06TB Host writes
MWI 44

[gojirasan]

Groberts101, have you actually read more than the last few pages of this thread? You seem to be completely unaware of Ao1's testing. And your description of throttled states doesn't sound right at all to me.

As Tony states on the OCZ forums a "fresh" state is mostly irrelevant. You always have to assume garbage collection and possibly TRIM on these drives. It's just part of the process. A direct result of one of the drawbacks of flash NAND. It might make sense to call that a "settled state" since the drive has settled in to where it should stay in the long run. IOW it has to start dealing with garbage collection and TRIM. Your claim that this is the Duraclass "life throttle" seems a bit silly to me. It isn't any kind of throttle. It's just the normal garbage collection process making itself known. What you called a "hammered state" didn't seem to exist in Ao1's testing, although I believe that Tony claimed that there is such a state. It again just sounds to me like inadequate garbage collection needing extra time to catch up. Perhaps this would equate to the TRIM pauses Ao1 noticed. Brief stutters essentially.

Despite what you claim, according to both OCZ and Sandforce there is supposed to be an (optional) genuinely throttled state which exists solely for warranty purposes. If you don't like the term "life throttle" perhaps you could think of it as "warranty throttling" instead. The only reason for this slowing down of writes (to around 6 MB/sec in the case of Ao1's drive) is to make at least some effort to prevent warranty claims for non-consumer uses or 24/7 writing. In Ao1's case it sometimes seemed to slow down reads as well. Did you see that in your testing?

You also claim that secure erase will reset life throttling. I am curious about exactly what data you are basing this on. In Aoi's testing it took about 30 TB of writes before life throttling started to rear its ugly head. Once throttling did appear secure erase had no effect with the tools he was using. What tools did you use for your secure erase and what were your before and after write speeds?

[Note: I find your rather unusual method of trying to quote someone by adding your own red colored text to the quote extremely confusing and difficult to read. I had to check back a couple of times to make sure that Ao1 himself had not actually written what you wrote. There is a quote tag for a reason you know. Even italics would be easier to read than text color changes.]

[One_Hertz]

136.5TB. 29%. Reallocated sectors up to 8.

[bulanula]

SF vendors should come out and make a clear statement on exactly what throttling measures have been applied and what the impact will be.
It should be a clear specification on the product.

Would like to see this as well for the sake of transparency !

[Computurd]

Dudes, i want to test write endurance on these, but they have *unlimited* writes but a five year warranty so go figure, i wonder how that works if it stops working? actually it has a five year lifespan of unlimited writes. so you can write to it constantly, non stop for five years and still be covered!
never mind all that rambling, these are freaking awesome about to start totally going nuts testing these here shortly...
3.5" EFD (Enterprise Flash Drives)

[Computurd]

[Note: I find your rather unusual method of trying to quote someone by adding your own red colored text to the quote extremely confusing and difficult to read. I had to check back a couple of times to make sure that Ao1 himself had not actually written what you wrote. There is a quote tag for a reason you know. Even italics would be easier to read than text color changes.]

actually i quite like it. and might even steal the method and use it myself

@AO1...hey i recall that....seems that we based a good drive temp from that document to be 30-40C , i still set the curve on my fans on my HDD to never allow them to go over 40C because of that document. Even though the conclusion was that it didnt have a huge impact on performance, you can see in figure 4 that the best range for lowest failure is 30-40C. that is still widely held knowledge. google does us a great service releasing data like this!

[johnw]

actually i quite like it. and might even steal the method and use it myself

I did not even realize he had inserted his reply in that long quote until someone pointed it out.

So feel free to use the technique. I'll probably miss your replies, too!

By the way, I'd say the safe range is more like 25-50C from that graph, although the error bars are large over 45C, so it might be better to set the upper limit at 45C, then to make it almost symmetrical, the lower limit would need to be like 30C. So 30-45C.

[Computurd]

37-44 actually looks the absolute best to me so now i need to reset my curve

[Ao1]

Can't say I'm too happy about how those comments were inserted. I'm not bothered by what was written, but I am bothered if people think I wrote them.

Anyway, looks like the MWI does not get to 0.

From the toolbox release note:

" The normalized value declines linearly from 100 to 1 as the average erase cycle count increases from 0 to the maximum rated cycles. Once the normalized value reaches 1, the number does not decrease, although it is likely that significant additional wear can be put on the device. Use the Normalized value for this attribute".

Also for data integrity checking the toolbox can run two types of scan:

7.0 Run Fast Diagnostic Scan
Use this option to perform a quick check on the health of an Intel SSD.
The scan checks 1.5 GB of the SSD for READ errors. The scan then creates 1 GB of random data and then compares it for data integrity. The scan takes approximately three to five minutes to complete and requires a minimum of 5GB of unutilized space to run.


8.0 Run Full Diagnostic Scan
Use this option to perform an overall health evaluation on an Intel SSD.
After checking every logical block address (LBA) for READ errors, the scan uses the free space to write random data and then reads it back to ensure data integrity. This scan can take an hour or more to run, depending on the amount of free space on the drive, and requires a minimum of 5GB of unutilized space to run.

[One_Hertz]

139TB. 28%. Reallocated sectors up to 9. My reallocations are going up quite a lot lately.

[Anvil]

104,68TB Host writes
MWI 42

Still at 6 reallocated sectors, been a while since last time it changed.

[gojirasan]

139TB. 28%. Reallocated sectors up to 9. My reallocations are going up quite a lot lately.

I guess the wear leveling is not perfect.

Even if your drive failed right now that would mean over 142,000 GB of writes. I figure I would write no more than 30-40 GB per day to the drive, although I want to figure out a way to do a better estimate of my writes. If I assume 40 then 142,000/40 = 3550 days = 9.7 years which is a long time. And since I'd be buying either a 120 GB or 240 GB drive it should actually last me more like 30 - 60 years, which is nice. I just wish the price/GB would drop. It seems like the 25nm drives haven't dropped in price at all. In fact most of the time they seem to be more expensive than the 34nm version. For instance the 256 GB C300 is actually $10 more than the m4 on Amazon.

I really want to thank you guys for doing this testing. Somehow it has made me more gung ho about SSDs in general. It really does seem like Intel has somehow magically been able to get something like 5000 p/e c. from their 25nm chips, making me a lot less reluctant to get a drive that uses 25nm IMFT. I'm just waiting for the right sale to buy one. Probably either an Intel 510 or a Sandforce drive. Probably an Intel because I hate Sandforce's fascist warranty throttling policies and Intel SSDs will work better on OSes other than Win7 or Linux due to their SSD Optimizer software. That's also an advantage Intel has over those rather nice Crucial drives. Not everyone in the whole world runs either Win7 or Linux with TRIM. The problem is the Intel drives are way overpriced. The Crucial and Sandforce drives are priced much better. So I'll just wait. Maybe the 25nm price will drop when the 20nm IMFT drives are released.

[One_Hertz]

I guess the wear leveling is not perfect.

Or not all cells are created equal...

[johnw]

Did you mean you will get an Intel 320? The Intel 510 series use 34nm flash.

Also, some of the Intel 320 SSD's are significantly cheaper than the 34nm X25-M. The 160GB X25-M has long been around $400. The 160GB Intel 320 is about $300, and I got one for $280. And the 320 actually has 176GiB of flash on-board, as compared to 160GiB with the X25-M. The 320 uses the extra flash for RAID-4-like XOR parity.

[groberts101]

Can't say I'm too happy about how those comments were inserted. I'm not bothered by what was written, but I am bothered if people think I wrote them

sorry... is just a force of habit due to the ease of which it can be done on my end. If you noticed the post above it was worded better as to not mesh so easily into the original post and was obviously a response to each section of the original post. I'll break it down into individual quotes next time so there's no confusion or animosity caused. Will also revist that post of concern to clarify for anyone else reading it in the future.

As for the other questions about my source of info or credibilty on the subject of Sandforce?.. well.. not sure Tony will admit to it or not(he's English you know.. lol) but I do know that all my testing and feedback on the original Sandforce controller(not to mention the new one) has helped to form the basis of overall understanding for these controllers in general on that forum as well as around the web due to the trickle down effect. IMO, that advanced understanding is what earned me the opportunity to beta-test these new SF2281 6G controllers.

Many of the advanced users and one's who lower gaurds and test theories/advice are happy with the info and tweaks that I helped uncover about these drives and most was done simply because of the shroud of secrecy that Sandforce perpetuated(I know/was told they were watching along the way as things were put into the public domain). Tony helped as much as NDA and his personal testing would allow but I seriously pushed hard to get more info(rallied other users into my cause) and testing from my end with posted/quantifiable results was the ONLY way that I could get to the end result. Which ultimately was only the need to understand them to better work around their inherent weaknesses and better implement them into my vid/gfx workstation usage.

Again with the not trying to toot my own horn here.. but many of my "extreme views" have been inplemented into the stickies and are now used as common "extreme usage" protocol to squeek that last bit of performance/stamina out of these controllers. So while I can't take the complete credit for "heavy user implemented OP/unallocated space, logged off idle recovery, and SE/reimages to recover immediate fresh speed"?.. I certainly pushed the envelope and lead the way with MANY TB's worth of test data and result responses over on that forum. Mine aren't generally the little 2 sentence chats either. I speak in great detail and give several iterations to get my points/results/test methodology across. Had to constantly break my posts due to the 5000 word v-bulletin forum limits. lol

So,.. if you guys don't mind me breaking it down and cluttering this thread a bit more than usual?.. I can feed info for those who have actual interest for the facts about these controllers. Most will be more of "what they do" moreso than "why they do" but the end results will be the same. If you want to tear at me and diminish my knowledge to fit into your nice little "this is my Sandforce understanding" bubble?.. I don't have that kind of time and won't be drawn into debates when the guards are up and the mind is closed. Keep the questions broken down and in simpler terms and I'll try my best to tell you what I know so far. If I don't know?.. I'll tell you my opinion or speculate based on others feedback(some of Tony's as well).

[johnw]

Again with the not trying to toot my own horn here..

Think what you could do if you were actually trying!

So,.. if you guys don't mind me breaking it down and cluttering this thread a bit more than usual?.. I can feed info for those who have actual interest for the facts about these controllers. Most will be more of "what they do" moreso than "why they do" but the end results will be the same. If you want to tear at me and diminish my knowledge to fit into your nice little "this is my Sandforce understanding" bubble?.. I don't have that kind of time and won't be drawn into debates when the guards are up and the mind is closed. Keep the questions broken down and in simpler terms and I'll try my best to tell you what I know so far. If I don't know?.. I'll tell you my opinion or speculate based on others feedback(some of Tony's as well).

Two things:

1) Probably best to start another thread

2) You might try reading what others have written and respond to people. You still have not responded to Ao1's data about how his Sandforce drive was lifetime throttled to 7MB/s sequential write speed, and it stayed throttled despite several secure erases. Clearly, SE does NOT clear a lifetime throttle condition on Ao1's SSD.

[zads]

...I have SE's numerous times and its only idling that does anything.
...
SF vendors should come out and make a clear statement on exactly what throttling measures have been applied and what the impact will be.
It should be a clear specification on the product.

Okay I qualify here-
Its lifetime/warranty wear leveling,
Can't be cleared by secure erase or even firmware upgrade,
can only be cleared by a base-level manufacturer's firmware load.

...
Despite what you claim, according to both OCZ and Sandforce there is supposed to be an (optional) genuinely throttled state which exists solely for warranty purposes. If you don't like the term "life throttle" perhaps you could think of it as "warranty throttling" instead. The only reason for this slowing down of writes (to around 6 MB/sec in the case of Ao1's drive) is to make at least some effort to prevent warranty claims for non-consumer uses or 24/7 writing. In Ao1's case it sometimes seemed to slow down reads as well. Did you see that in your testing?

You also claim that secure erase will reset life throttling. I am curious about exactly what data you are basing this on. In Aoi's testing it took about 30 TB of writes before life throttling started to rear its ugly head. Once throttling did appear secure erase had no effect with the tools he was using. What tools did you use for your secure erase and what were your before and after write speeds?
...

Lifetime write throttling should not affect read speeds unless its doing other processes in the background simultaneously (which is likely in this sort of high-load environment).
No type of secure erase will reset life throttling curve. See above response.

Dudes, i want to test write endurance on these, but they have *unlimited* writes but a five year warranty so go figure, i wonder how that works if it stops working? actually it has a five year lifespan of unlimited writes. so you can write to it constantly, non stop for five years and still be covered!
never mind all that rambling, these are freaking awesome about to start totally going nuts testing these here shortly...
3.5" EFD (Enterprise Flash Drives)

Interesting, where did you get the Pliant drives from?
You work for a company that uses them?
What were you saying about SLC NAND being a dead market?
If only I could say what we're building for the GOOG...

...
It seems like the 25nm drives haven't dropped in price at all. In fact most of the time they seem to be more expensive than the 34nm version.
...
It really does seem like Intel has somehow magically been able to get something like 5000 p/e c. from their 25nm chips, making me a lot less reluctant to get a drive that uses 25nm IMFT.

NAND shortage in supply (relative to boom in demand)= price drops are stabilizing
The 25nm flash you guys will see is going to be 3k.
The 5k/10k stuff doesn't go into consumer products.

...
SF drives cannot sustain performance levels without burning up the NAND, despite the compression advantage, hence the drives are life time throttled.

Intel drives provide consistent write speeds throughout the life of the product and regardless of xfer size. SF drives can't do this.
...

Sandforce does better than Intel in terms of "burning up the NAND", and Intel isn't consistent write speeds throughout the life of the product either.

i feel it is indicative of their intended path that they are now releasing enterprise SSD "drives" with 25nmMLC and no mention of 25nm slc anywhere.
...
the extrapolation of this point is the comparison of SLC v MLC in the enterprise space. With SLC so cost prohibitive, and MLC gaining rapidly with endurance, it is simply much much smarter to use MLC in the first place, and get it over with. Eat the cost of the reduced endurance, but in the end, you are going to come out way ahead in cost per transaction.
Also, in todays data center, effective tiered caching is going to allow you to further enhance the viability of your MLC drives.
...
but when? and where? no time in the near future.
...

Intel is going eMLC for their enterprise class 2.5" because it makes sense for the majority of the market, true- that's who Intel builds their products for!
That certainly doesn't mean SLC is dead/unnecessary/less cost effective in many "enterprise" scenarios..

[Ao1]

Please see post #237 & #258. Compressed read speeds are impacted. Non compressed read speeds are not impacted.

Regading Intel drives please see post #482 No slow down that I can see. Also I've never seen more than ~5% change is sequential write xfer speeds, no matter how large the xfer is.

Regarding nand burn out, if compression is so good why is life time throttling required?

The SF-2281 has more throttling options (Compared to the last gen). That can impact burst IO and slow down writes/ reads. There are probably other way the drives are impacted. SF vendors need to come clean and say what options they have selected and give details of the boundaries to keep within to avoid issues.

[Computurd]

nteresting, where did you get the Pliant drives from?
You work for a company that uses them?
What were you saying about SLC NAND being a dead market?
If only I could say what we're building for the GOOG...

yeah they are Pliant LS 300S 3.5in 300 GB SLC drives...very cheap so i bought five of them
(Just kidding, they cost $34,000 USD for that little pile there, they are on loan for some reviews of them and several raid cards, enclosures, blah blah blah)

ntel is going eMLC for their enterprise class 2.5" because it makes sense for the majority of the market, true- that's who Intel builds their products for!
That certainly doesn't mean SLC is dead/unnecessary/less cost effective in many "enterprise" scenarios..

yes, that is exactly what i am driving at in the first sentence. SLC is a niche market. Yes, it will be out there, but as it falls further and further into the niche market we know what happens, it gets even more and more expensive, thus dying off. it will become increasingly less cost effective as time wears on. that is why Intel abandoning them for SSD "Drives" is met with disdain by many. it heralds the beginning of the end. less mainstream=less investment=less innovation=more expensive
never questioned the performance/reliability of SLC. just hit 440,000 IOPS with five devices a while ago. very impressive.
Is SLC necessary? somewhat right now, as things stand. However, as SLC falls more and more into the niche market MLC will get all of the attention/research/innovation, and will deem SLC unnecessary with future generations/shrinks of nand(that is my speculation of course, but felt by many). think-today eMLC...whats tommorow? eXMLC? lol you get the point.
I do seem to remember though that in the heady fast and furious days of SSD first hitting mainstream how everyone talked about the progress/maturation of MLC would eventually bring SLC and its exorbitant prices out of the equation, and that being a good thing.
now we have almost reached that point and everyone is unhappy. go figure.

If only I could say what we're building for the GOOG...

actually i think i know what it is