[PATCH]fs/jffs2/wbuf.c: add compatibility support for OOB data block
Jörn Engel
joern at wohnheim.fh-wedel.de
Mon Aug 15 09:51:58 EDT 2005
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
More information about the linux-mtd
mailing list