Treatise on Formatting FLASH Storage Devices

Hal Murray hmurray at megapathdsl.net
Sat May 16 01:28:14 EDT 2009


[Apologies for the delay. I typed most of this in a long time ago, then I got 
distracted.]

Mitch: Many thanks for the heads up.  I think I knew about most of the 
quirks, but I
hadn't noticed the interactions of the alignment preferences before.

Al Fazio is Intel's flash guru/evangelist.  He gave a talk at Stanford last 
Nov.  He's going after the disk market.
  http://www.stanford.edu/class/ee380/Abstracts/081112.html

You may be able to watch the video here:
  http://www.stanford.edu/class/ee380/fall-schedule-20082009.html

His slides have a lot of good numbers and background info on flash technology.

Intel is now selling flash based "disks" for laptops.  Expensive, but no 
moving parts.  Also, very low power when they are idle.


What I remember from his talk:
  Raw flash chips leak and wear out.
  Reads contribute to the wear.

  Newer chips are denser and wear out faster.

  For cameras, the numbers are OK.
    The total number of writes/reads is small because they are all caused by 
a human pushing a button.  Even if you push the button a dozen times in row, 
that's tiny relative to a disk file system

  For use as typical PC file systems, the numbers are horrible.

  Intel did a lot of work in this area...
    ECC and such at the word/block level
    Lots of heuristics for wear leveling and avoiding writes
 
and probably a few more interesting things that I have forgotten.

There is no seek time on flash disks.  They did a neat demo.  They setup a 
big box full of their Flash disks and ran one of the standard database demos 
at blinding fast speed.

---------------

The wear-out is interesting.  Nothing else in computers works that way.  
Computer geeks don't have any experience thinking about that aspect of a 
problem.

--------------

Somebody mentioned log structured file systems...

At the hardware level, the basic flash chip is not restricted to writing 
pages.  An erase sets each byte to all ones.  Writes turn them off.  You can 
turn off more bits with another write to the same location.  Thus you get 9 
states out of a byte before you have to erase again.

So for an append-only file, if you don't need the value of 0xFF, you can 
append with no extra-write penalties.  (that assumes you are happy without 
ECC and such, but you could add ECC at the record/line level



-- 
These are my opinions, not necessarily my employer's.  I hate spam.





More information about the Devel mailing list