[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: garbage collect
On Sat, 24 Jun 2000, Jason Gunthorpe wrote:
> 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.
Yes. In our products we have one read-only filesystem and one r-w system,
so we dont get the problem you describe below.
> 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!
I know. We need to add that to JFFS as well sooner or later..
> 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)
Yeah, you dont even need to store the mapping in the flash either because
the scan does not care if it scans in weird order.
Do you have a scoring function to propose ? I guess some heuristic tests