Re: [PATCH]fs/jffs2/wbuf.c: add compatibility support for OOB data block

["Jörn Engel" <joern@wohnheim.fh-wedel.de>]

On Mon, 15 August 2005 17:38:41 +0400, Artem B. Bityuckiy wrote:
> 
> Ok, let's change JFFS2. I would prefer just alwayse assume 1:1 mapping 
> and always use vmalloc in JFFS2 for c->blocks[] (no 128K limitation).
> 
> For compatimility, we need to be able to fallback to the old JFFS2 
> algorithms.
> 
> And here we definitely must introduce the way to recognise versions of 
> the image. We may introduce the version number to clean markers. We also 
> must set INCOMPAT flag in clean markers to prevent new images to be 
> mounted by old JFFS2s. New JFFS2s will mount the FS only if the version 
> is <= then the current JFFS2 version. Something like this. Versioning 
> will anyway be useful in future.

JFFS2 doesn't have a superblock.  Where should the versions be stored?

I'd create a new node with INCOMPATIBLE flag set.  That's the JFFS2
translation of what you just stated.  Converging this node with
something else like the former erase marker would make sense, yes.

> Moreover, Forrest is adding the trick to store the erase count at the 
> beginning of each eraseblock. So, we may store this erasecount in clean 
> markers as well. Then we may rename "clean marker" to "node header".

Sane.  We can combine these changes.

> On NAND, clean marker is in OOB of the first page. As new cleanmarkers 
> become larger, we may span them to the 2nd, the 3rd, etc OOBs.

You're the expert here.

Jörn

-- 
Linux is more the core point of a concept that surrounds "open source"
which, in turn, is based on a false concept. This concept is that
people actually want to look at source code.
-- Rob Enderle