On Mon, Sep 18, 2006 at 02:11:29PM -0500, Dave J. Barnes wrote:
> There is no need for a special FLASH FileSystem since the U3 cpu does 
> FLASH write wear-levelling, ie.
> 
>    "When a file must be updated, TrueFFS does not overwrite the old
>    data. Instead, it writes the new data to unused blocks and directs
>    subsequent read accesses to these blocks. The old data is marked as
>    "old", and is not erased until the block has to be reused."
> 
> Hmmm. You could run an O/S on the U3 without fear of wearing out a FLASH 
> cell. No rotating disk drive needed.

Every USB flash and CF device does that.  I hate to spoil the marketing
hype with reality, but it doesn't work as well as you think.  Generally,
there is just a reserved pool of spare blocks.  If you continually write
to the same block (e.g. the superblock), you'll just end up rotating
through this pool rapidly.  That may extend the life of the device, but
it does not make it infinite.

Prior to my changes to defer atime updates, the half-life of a CF boot
device under NetBSD was about 6 months.  I have several dead ones.

But there are other reasons to want a "flash file system" as well.

* FFS requires updating several blocks whenever you modify a file, which
  is slow.  This is primarily because it uses extra data structures to
  speed up certain operations -- but on a flash device this causes a
  large loss of performance in other cases.

* The aforementioned data structures also consume space, which is still
  a concern for smaller flash devices (often embedded in consumer
  electronics).

* FFS can't group things into erase blocks (usually 128KB or so), which
  gains you a lot of efficiency on bulk writes, without wasting a lot of
  space for small files (c.f. maximum fragment:block ratio of 8:1).