× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



Take a 177GB drive and assume cells can start failing after 3000 writes,
there's no slack space/overcapacity, but the drive has a good wear leveling
algorithm. That would suggest you can write 531,000GB before the first
cells start to fail. If you figure a 5 year duty cycle for the drive you
can write 290GB per day.

Now, extend that by adding in for the slack space. Most SSDs have 7-11%
extra capacity but of course it can be higher. Keeping with the worst-case
picture, 7% bumps the daily writes up to 311GB, which works out to about
13GB/hour or 216MB/minute for every minute, 24 hours per day, for 5 years.

If the IBM drives use SandForce controllers, extend that even more as the
SF controllers do both compression & data deduplication.

If IBM speced cells that are good for 10K writes v. the 3K minimum, then
the writes-before-a-cell-wears-out more than triples.


On Thu, Dec 1, 2011 at 12:03 AM, Pete Massiello - ML <
pmassiello-ml@xxxxxxxxxxxx> wrote:

Joe,

I put some SSDs in a Power6 520 2 years ago, it is an I/O intensive
machine. We moved all the heavy I/O files to the SSDs, performance is
great, and we haven't replaced one SSD yet. I enjoyed reading all your
technical specs, just reporting what I have out in the field.

Pete

Pete Massiello
iTech Solutions
http://www.itechsol.com


-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx [mailto:
midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Joe Pluta
Sent: Thursday, December 01, 2011 12:40 AM
To: Midrange Systems Technical Discussion
Subject: Re: SSD Analyzer Tool

"Reliable enough" leaves a whole lot of room. The problem with
reliability is the number of charge states required per cell. SLC devices
store one bit per cell and so you either need on or off; it's pretty
simple. MLC devices typically store two bits per cell, and so require four
identifiable states and those degrade pretty quickly. The numbers I've
seen are somewhere around between 3000 and 10,000 writes (as opposed to
100,000 for SLC). That's NOT a lot of writes unless you have a really,
really good load leveling algorithm. Not to mention MLC is much slower. I
think IBM uses eMLC, which is a compromise design with more writes but is
even slower still especially on writes.

So, back to the question at hand, what's "reliable enough"? We update our
item master with every shipment. We ship hundreds of times a day.
To have cells die after a few thousands writes is awfully frightening.
On the other hand, for a mostly read-only drive like a load source there's
something to be said for SSD. I'm designing my next workstation and I may
go with two different SSD drives, one for boot / program load and one for a
scratch drive (things like workspaces for my Rational products). The
thought is that the scratch drive can be replaced as needed without
affecting the load partition, and I'll have a traditional hard drive to
store low-priority data and also to back up the SSDs.

Joe

The original 70GB SSDs were SLCs as I recall. These were actually
128GB devices leaving significant capacity for re-maping worn out areas.

The current 177GB SSDs are MLC devices. I don't have information on
the overcapacity of these devices but suspect perhaps 256GB is the
likely size.

IBM would not ship an enterprise class device on POWER systems if they
did not believe that they were reliable enough for the task at hand.

- Larry "DrFranken" Bolhuis

On 11/30/2011 10:18 PM, Joe Pluta wrote:
What kind of SSDs are they? SLC or MLC? Any information on how long
they last? Because the MLCs are notoriously short-lived. A lot of
that depends on the data use algorithms.

Joe

--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing
list To post a message email: MIDRANGE-L@xxxxxxxxxxxx To subscribe,
unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx Before posting, please take a
moment to review the archives at http://archive.midrange.com/midrange-l.

--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.





As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.