Flash FS

It's one of those things that sounds trivial, until you look into it in more detail. That said it's not going to be that much code, it's more a case of decision making and tradeoffs.

I have a *very* rudimentary filesystem working, however I'm still going through the throws of making fairly fundamental choices about how to implement the code and what limitations to put on the design.

Limiting it simply to 256Mb of flash would make life fairly easy (!) as the amount of memory consumed and mount times can be completely trivialised (compares to jffs2 timings).

The current concept (which is probably going to be the final idea) limits the filesystem size to 64Gb, which would imply a mount time of a number of seconds (yet to be determined, but probably sub-10) however this should cope with key sizes for quite some time to come. The reasons for this limitation stem from choices made mainly about memory consumption .. so removing this feature in the future would be relatively easy if memory and mount times are less of an issue.

So targets for the filesystem are; (based on a full 256Mb key)

• Journal / Log structured design aiming at minimal sequential writed only
  
• Sub 1 second mount time
• Sub 5M memory consumption
• Inline compression with at least the same efficiency as JFFS2
• Ability to run natively on any block device (unlike JFFS2)
• Ability to run (effectively) as a root filesystem on a hard disk with a size up to 64Gb
• Portable code that can be implemented under Windows (et al) for compatability

It's coming along slowly .. I might get chance to do a little more now I've managed to re-align my Sky dish and have a TV signal again .. the effects of global warming even extend to knocking out satellite communcations .. bloomin wind .. (!)