Re: SSD Analyzer Tool

On 12/1/2011 6:54 PM, Don wrote:

Well, I do remember bubble memory...and even core...

I think the concerns are valid, but I also think that IBM has addressed them
in design and automatic allocation and assignment of alternative cells
should a cell fail. As I understand it, this all happens transparent to the
user and there's been considerable testing and contingency planning if and
should these internal failures occur such that there's ample internal
failure space (for lack of a better term) to handle a helluva lot of memory
space fatigue...

I've not heard of any issues with SSD hitting MTBF and failing/faulting to
any unacceptable rate of yet. I spoke with IBM'ers at CES last January on
this and will refresh it next month while in Vegas again. I think what
you'll see in time is substantial SSD for laptop/tablet products and even to
the point of allowing mirroring on laptops in the near future...which is
something for higher end uber-power users that's becoming a must.

Yeah, but most people don't really understand how these drives work. I've read quite a bit and I still think it's crazy. For example, you don't actually write a byte on a drive. You can clear bits (but not set them again!). You can only set an entire block at a time. For purposes of illustration, a byte starts at b'11111111'. You can then set that to x'F7' (b'11110111') because you are changing one bit from 1 to 0. You can then change that to x'40' (b'01000000') because again the only bits that are changing are changing from 1 to 0. Now, though, say you want to change back to x'F7'. No can do, buster, because that would require resetting some bits from 0 to 1. And the only way you can do that is by resetting THE ENTIRE BLOCK and then rewriting all the data (including the new x'F7').

So in reality, changing a single byte may require an entire block to be rewritten. And you know what does that? A busy flag on an item record. Back and forth, back and forth. Every time that flag gets set and cleared, you have to reset and rewrite the entire block it lives on. And I'm sure that remains transparent to the application program, but nonetheless it's a whole lot of bytes getting flipflopped (typical block sizes on large SSD drives range from 8K to 16K).

That's why I want to see these things in real use on live enterprise level systems for a couple of years. That's all I'm saying.

Joe