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 15:34:09 +0200, Ferenc Havasi wrote:
> 
> But If I am right we use kmalloc, and its limit is 128K. Why don't we 
> use vmalloc() instead there?

You're right, it was kmalloc and not vmalloc.  Fundamental problem
remains, though.

I went through this with Artem on irc.  We haven't found a solution
yet, but here are some of the bits and pieces.  Maybe someone can
assembler them into something sane.

Constraints:
1. Once a jffs2 partition/image is created, the virtual erase block
   size may never, under any circumstances, change.
2. Virtual erase block size must be stored in a way that it will
   *always* be read during mount, preferrably early on.

A simple solution for this problem is virtual size == physical size.

One reason to aggregate physical blocks into virtual ones is to save
memory.  The aggregation code makes sure that we never spend more than
128k on the array of struct erase_block.  Not sure if this is really a
valid concern, though.  Once we have such a big flash, jffs2 will
require tons of memory anyway.

If we go for a virtual:physical mapping other than 1:1, we need to be
safe against this scenario:

1. we have a flash with N erase blocks, 1:1 phyical:virtual mapping
2. first erase block is being erased
3. power-fail during erase, block is all FFs
4. resize of partition
5. with new partition size, physical:virtual mapping is N:1
6. no more block headers at the beginning of a virtual block

Jörn

-- 
Why do musicians compose symphonies and poets write poems?
They do it because life wouldn't have any meaning for them if they didn't.
That's why I draw cartoons.  It's my life.
-- Charles Shultz