Axis log based flash filesystem ported to 2.3 and MTD

[Finn Hakansson]

On Mon, 27 Mar 2000, Bjorn Wesen wrote:

> On Mon, 27 Mar 2000, David Woodhouse wrote:
> > >  The flash is not divided into blocks in our JFFS. The flash is
> > > logically a single circular append-only file (but with random access
> > > of course). Wear-leveling comes implicitely in that model, since the
> > > log-file is circular. 
> > 
> > When you append to your circular log, you end up eating your tail. What if the 
> > erase block you're about to 'eat' doesn't contain any data that needs to be 
> > changed. Do you leave it alone and skip it, or do you erase it anyway?
> 
> The garbage-collector is invoked when the amount of headroom starts to get
> low compared to the amount of redundant areas in the flash. It will start
> to erase sectors, and if they contain non-redundant info, it is moved to
> the head first. Finn can fill in here in more detail.
> 
> As you see it's important that the GC is triggered at the right time. If
> you end up with 1 byte head-room before the GC, you cannot move data out
> of the way of the sector-erase. 

Yes. There must always be enough room to perform garbage collects. The
room absolutely needed in JFFS is more than 1,5 sectors. This means
that at least 1,5 sectors of the flash device are unused.

Before every write to the flash, we make sure there is enough space
left on the device. Deletions are always allowed though.

After every completed write to the flash we check if we have to issue
a garbage collect.


> The parameters of the GC are chosen so they work for us, but they are
> subject to tuning of course.

There is a function in JFFS called jffs_garbage_collect which contains
the criteria for garbage collects that, for the moment, suit our
products. As Björn stated, this function could be used as is, but could
of course be tuned to fulfil slightly different requirements.

/Finn



To unsubscribe, send "unsubscribe mtd" to majordomo at infradead.org