safe flash filesystem

[Abraham vd Merwe]

Hi Russ!

> > Yes, this is something in the lines I was thinking of. But what complicates
> > things is if you start taking things like avoiding damaged blocks into
> > account, wear levelling (this is fairly easy to solve) and keeping the flash
> > unfragmented.
> > 
> if you only eraseblocks when you need to, you always have at least N-1 
> eraseblocks of pevious data, (where N is the number of eraseblocks 
> used). A CRC can be done after the store to see if the node written is 
> ok, if not, write it again (in the next node). since its a small amount 
> of data (maybe 4-8k) and written linearly, wear leveling and 
> fragmentation is not a problem. Lets say 4 parameter blocks of 16k a 
> peice are used, that would be 1 erase cycle per 8 configs written, this 
> would allow 800,000 configs to be written on standard flash. If a config 
> was written at a rate of once an hour, it would last 93 years. If it 
> were on 2 128k standard blocks, then you wolud have 3.2M configs 
> written, which at the same rate, would last about 332 years. Remember, 
> you are only performing an erase cycle after a block fills up, not for 
> every write.

True, but once the flash fills up you have to start moving things around to
erase entire blocks and then the whole 4k-8k thing doesn't hold anymore.

But anyhow, like you said, it's not the most complicated thing in the world.

-- 

Regards
 Abraham

You don't have to know how the computer works, just how to work the computer.

__________________________________________________________
 Abraham vd Merwe - 2d3D, Inc.

 Device Driver Development, Outsourcing, Embedded Systems

  Cell: +27 82 565 4451         Snailmail:
   Tel: +27 21 761 7549            Block C, Antree Park
   Fax: +27 21 761 7648            Doncaster Road
 Email: abraham at 2d3d.co.za         Kenilworth, 7700
  Http: http://www.2d3d.com        South Africa

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 232 bytes
Desc: not available
Url : http://lists.infradead.org/pipermail/linux-mtd/attachments/20010625/274176c6/attachment.bin