On Tue, Mar 21, 2006 at 11:36:24PM -0800, Garrett D'Amore wrote:

Another 2cents from myself...

To my nowledge NOR flash (I don't know anything about NAND flash, except
from reading this thread) has the following properties:

1) The 'erase block' size is typically 64k (128k when two 16bit parts
   are used to effect a 32bit device).
2) Erase is the only way to convert a bit from a '0' to a '1'.
3) Erase is very slow (~1 second on the devices I was using).
4) There is a limit of the number of erase cycles that can be done
   on each erase block before the data retention time is reduced
   below an acceptable level.
5) Individual bits can be written to change from '1' to '0'.
6) Write isn't that slow.
7) You can't do reads or writes while an erase is in progress.

Any simple mapping of the flash device to a filesystem will suck due to
the slow erase time.  This can be alleviated by some simple caching
strategies - at the cost of losing data on a power fail.

Standard filesystems are 'flash unfriendly' for a variety of reasons,
including:
1) Not telling the device when sectors are no longer needed
2) Repeated writes of metadata sectors.
3) Initialising data to 0 and not allowing both 0x00 and 0xff to mean
   'nothing present'
4) inode atime/mtime updates
5) Not using single large (aligned) writes for write to large files.

I actually suspect that if the filesystem did (1), allowed directory
block and file allocation maps to be specified with 0xff => unused space,
and that some other common inode updates were not done (or modified)
the something like FFS could be used with a FTL that does a block lookup
using data saved in a couple of flash sectors.
(I'd write a logical_block+physical_block pair at the end of the lookup
table every time a block has to be reallocted. Using a couple of bits
to mark validity....)

	David

-- 
David Laight: david@l8s.co.uk