Re: JFFS2 eraseblock header

David Woodhouse
2005-09-08T13:32:44Z

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