JFFS2 eraseblock header

[David Woodhouse]

On Tue, 2005-08-16 at 12:22 +0400, Artem B. Bityuckiy wrote:
> 1. Get rid of clean marker and use eraseblock header instead (the 
> eraseblock header will play the role of cleanmarker).
> 2. The length of the eraseblock header will not be constant, it may grow 
> with growing version.
> 3. As it is implemented currently, store the eraseblock header at the 
> beginning of the eraseblock, in OOB for NAND.
> 4. For NAND, we assume the eraseblock header may span several OOBs, not 
> only the first page's.

OK.

> What's with compatibility?
> ~~~~~~~~~~~~~~~~~~~~~~~~~~
> 
> 1. Old JFFS2 binaries have to reject mounting new JFFS2 images (for 
> example, because we are going to change the phys:virt mapping to 
> constant 1:1, which is anyway incompatible). This is the problem in NAND 
> since the compatibility bits are not checked in clean marker (see 
> jffs2_check_nand_cleanmarker()). We may solve this problem by, for 
> example, changing types of dirent/inode nodes and adding INCOMPAT flag 
> there (yes, this is ugly workaround).

Hm, OK.

> 2. New JFFS2, when mounting an old JFFS2 binary, will use old algorithms 
> (1:M mappings, clean markers).

Should it? I wonder if it should silently upgrade, instead? Or at least
have a mount option to make it upgrade? We want to leave the old format
behind...

> 3. If JFFS2 finds that the version of the image is larger, it will 
> reject mounting the image. This will be useful in future.

OK.

-- 
dwmw2