safe flash filesystem

[Russ Dill]

Abraham vd Merwe wrote:
> 
> 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.

you are overcomplicating things, there is one config file, and the flash
is filled linearly, so once a block is full of written configs (only one
of which being the current, valid config), the next eraseblock is
erased. There is no moving things around, once we fill a block, all the
other blocks have much older versions of the config, and we could care
less