× 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.



I'm not sure what your point is. At no point did I even imply that the system would crash or lose data or anything like that. I assume that when one of these drives goes casters up, you can replace it like any other drive. Even us non-hardware guys replace drives, Larry.

I've only been thinking of the MTBF of the drive vs. the cost and speed. Just wondering about the ROI, is all. No need to get out the long knives. I'd really like to know what the real world MTBF is for an SSD drive vs. other IBM drives, and then do a cost analysis.

I'm not even remotely suggesting IBM would want to put out defective drives. On the other hand, I might think that IBM would LIKE to create a market for a really fast drive that was a little more expensive and needed to be replaced a little more often than the standard drive.

Joe


Does anyone remember bubble memory on AS/400, iSeries, System i or POWER
systems?? I don't.

I know you are not a hardware guy, but really Joe. I ask again, do you
really believe iBM would introduce these things FIRST on their very
largest (and therefore highest profile) machines if they truly were not
ready for prime time? What do you think the publicity would be for a
customer with $10,000,000 of POWER Systems going "Thunk" because they
piled on a ton of data on storage that wasn't really ready??? I don't
see IBM legal letting that even be an option.

- LArry "DrFranken" Bolhuis


On 12/1/2011 5:22 PM, Joe Pluta wrote:
While I like the math, I'm not sure it's entirely that straightforward.
First, you're assuming that the first failure occurs after 3000 writes.
I'm really not sure that's the case or if rather that's more of a MTBF
sort of number. But leaving that, I don't know that simply multiple the
GB by 3000 is going to work. I believe you can only use the unused part
of the disk to rotate your writes. Thought exercise: if the disk were
80% full and if those files stayed relatively static, you'd reduce your
write pool accordingly. So now you've dropped your space by a factor of
five. Further, I think you have to deal with fragmentation; either you
have to keep a big index of free space, or you have to effectively have
a hard sector size with all that entails.

Personally, I'd be a little leery of dumping all my data to SSD just
yet. I'd probably want the dust to settle just a little bit. We've
gone through this before (does anyone remember "bubble memory")?

Joe


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.



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.