Dr. Hetzler pointed me at this
In a 30 second explanation of NAND flash, Steve concluded by saying “read the application notes!”

In my dazed state that sounded reasonable. Now that I’ve spent a few hours poring over them I’m thinking I should have asked him to go over it again. Sure, any fool with a PhD from CalTech can figure them out, but as I’ve remarked before, I’m not just any fool. Ah, well, live and learn, if you’re paying attention.

So take the following with a grain of salt. I’ve done my level best to decipher the app notes from several NAND flash parts. Yet timing diagrams and low-level commands aren’t my native language, so some details may be a little off. Honestly, some of these app notes seem designed to conceal as much about performance as they reveal.

Prefatory remarks
I was a little harsh with Samsung’s marketing the other day. “Clueless ‘droids” I believe I called them, because

. . . leaving access times and IOPS off the chart is just dumb. While your average American ultra-light notebook buyer may have no idea what those numbers mean, we do like numbers. So give us some, especially when it makes you product look really good.

In my innocence I assumed that the numbers would make their product look good
Turns out, I should have credited them with more cunning. And given myself credit for still having a few crumbs of innocence after 25 years in the computer business.

Understanding NAND flash organization
If you’re a little drowsy this might be a good time to get some coffee . . . .

As this graphic, borrowed from an STMicroelectronics data sheet, shows, NAND flash is organized rather differently than the sectors, tracks and cylinders we are used to in disk storage.

Pages, blocks, spares and a page buffer?
Pages are the basic unit, with one very significant exception: writes are block-only, not pages. There are some wrinkles with different parts, but in general, in order to write a page, the entire block has to be erased and then rewritten with the new page.

STM’s NAND parts are a little more flexible than others I looked at, because they allow up to three partial page writes (chip guys call writes “program operations” since they think EPROMs, but forget that, I call ’em writes) before requiring a Block Erase command.

Page writes are non-trivial
An STM page write consists of five steps:

1. One bus cycle to set up the page write
2. Four bus cycles to input the write address
3. Data is then loaded into the page buffer
4. One bus cycle to command the write/erase/read controller to start
5. The controller then writes the data into the page

Typically each page must be written to in order, so to write the last page of a block means writing every other page first.

Samsung claims about a maximum (in storage vendor lingo, maximum means “theoretically possible but you’ll never see it in real life”) random write bandwidth of 12 MB/sec. Let’s call it 10 MB/sec write speed on the 32 GB SSD. To write a full 128k block takes about 13 milliseconds. Block erases take from 2-6 milliseconds on the parts I looked at.

Oh, so that’s why they left out the IOPS
I’ve left out considerations of cycle times, wear-leveling and other data transfer operations that occur as a system gets ready to write to a NAND flash SSD. I estimate is that each random write takes 20-25 milliseconds, roughly the speed of a 1.8″ hard drive, or 40-50 random writes per second.

If you are used to a 7200 RPM drive, the slower write speed will be a noticeable slowdown.

The other half of the story
Any component is part of a system. How the system interacts with that component is crucial. For example, database systems for decades have worked to limit the number of writes through a variety of techniques.

So how bad can it be with a consumer OS like Windows or Mac OS X? Not as good as you’d hope.

Ever look at the metadata on your files? Notice that “Last modified” or “modified” attribute in the details view of Windows Explorer or the list view of OS X? Every time a file is opened and the slightest change made, a read becomes a write. Journaling your file system as you should? More writes. Lots of system files get changed – and their metadata updated – in background processes.

New indexing technology, Spotlight in OS X and Vista File Indexing also add to the write load. In short, desktop OSs fling writes around like confetti, instead of conserving them.

The StorageMojo take
NAND flash SSDs are not going to be an unalloyed win due to their anemic random write performance. How bad the damage will be depends on your workload. Large sequential write aren’t bad. It is the small writes that will kill SSD performance. Just how the OS interaction will shake out is anyone’s guess.

As a Macophile, I suspect Apple will be able to move faster modifying Leopard for SSDs, while Microsoft will, as usual, lag.

Hybrid drives that combine flash and disk into one unit will be faster on the read side, but with no advantage on the write side. Again, not quite the win that SSD innocents like me imagined.

Still, the advantages for battery life – although some disagree – weight, read performance and shock resistance will prove compelling for many. I still can’t wait to try one out on my notebook.

Comments welcome of course. If someone has better info on this issue, please comment and I’ll be happy to make updates.

Some references:
Samsung NAND flash paper
OneNAND Features & Performance
Flash SSD data sheet
ST flash part app notes
Intel SD74 NAND flash datasheet