[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: garbage collect
On Tue, 20 Jun 2000, Bjorn Wesen wrote:
> No, we move everything in the sector then.
Hmm. It seems to me that in a typically application you will have a fair
number of sectors that contain only read-only program data. I would think
you would want to advoid doing any rewriting of these kinds of sectors.
Typically over half the flash or more could be allocated to this sort of
thing, the rest would be config files and unsed slack.
How FFS2 is ment to select the sector to GC is based on a combination of
live bytes and past erase counts, it prefers to re-use mostly empty blocks
until their erase counts get high, then the intent is to transfer
less commonly erased sectors into that sector.
Always operating as a circular log will give quite good wear leveling, but
that might be counter-acted by having to do too many erasures by poorly
selecting a sector to reclaim!
If I understand what you have said, you might have a flash constructed
F- Full sector
E- Empty due to data erasures
H- Half empty
S- Your spare
Program using the flash is rewriting a small status file quite often. The
diagram shows all the blocks and we are doing a write that has exhausted
the tail of the log. So by my understanding JFFS will write the entire
contents of block #1 to S and make #1 the spare, discover that #1 is full
and still cannot write, and repeat this until it gets to the first E! That
is 6 uneccesary erases?
Or am I reading you wrong?
> the flash. However the allocation scheme for writing to "the end of the
> log" will be quite more complicated.
Do you think? I could envision it being fairly simple, all you need is an
array mapping your 'logical' sector into a 'physical' sector. logical ones
operate in a purely circular way, the physical/logical mapping is selected
based on aging and fill like FFS2. (this last bit could be difficult
to tune correctly, but is really just a scoring function)