NAND partitioning

[Josh Boyer]

On Mon, 2005-01-31 at 13:56 +0100, Jörn Engel wrote:
> On Sat, 29 January 2005 09:51:00 -0600, Josh Boyer wrote:
> > 
> > Not necessarily.  I was actually thinking of having JFFS2 just "ignore"
> > such eraseblocks.  Essentially treating them as bad blocks perhaps.
> > 
> > However, such blocks could be scattered across the entire device rather
> > than contained within a certain address range on the chip.  Updating the
> > data would be a bit tricky, which is why I said a driver would need to
> > be created in order to deal with it.
> 
> Problem would be trivial to solve, if said blocks were not scattered
> across the device.  Do you have a good reason to need this?

If said blocks were not scattered across the device, then they could be
in a static partition and there would be nothing to discuss :).  We just
got done discussing this on IRC, so I'll try and summarize.

The main reason to not have static partitions is the concern of bad
blocks on NAND and the effects that can have on the available space for
updates, etc of binary data.  If a majority of a partition is bad
blocks, either from the factory or from eventual wear, then you don't
have much room for updating, etc.

Without a static mapping, one could "steal" free eraseblocks from JFFS2
to update or grow the binary data.  That would allow one to relocate the
binary data to different eraseblocks that might not be physically
contiguous.

There are problems with such an approach though.  Thomas pointed out the
AG-AND radiation problem, which is not trivial to solve.  Also, a hook
into JFFS[23] would be needed in order to ask it for eraseblocks if the
filesystem were mounted.

Artem asked about how this effects wear-leveling.  By allowing binary
data to be scattered throughout the device, it helps alleviate updates
to the same eraseblocks in a static partition.  One could even be
ambitious and make JFFS[23] move around such eraseblocks if they weren't
in use at the current time.  (Although that would present problems of
it's own.  I suppose you'd have to be quite ambitious to get that
working ;) ).

josh