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 16:38:45 +0400, Artem B. Bityuckiy wrote:
> Ferenc Havasi wrote:
> >I only say that for a user the size of the virtual erase block may not 
> >be evident. They know about the real erase block size. Maybe we should 
> >write a tool for calculating it.
> Why not to just copy the algorithm from JFFS2 (it is in 
> jffs2_do_fill_super())?

Because it's not good enough.

> >It is not too relevant problem without summary. For example if the erase 
> >block size is 32K, and the virtual is 64K, and you generates JFFS2 
> >image  for 32K it will work (maybe with some warning but will work). If 
> >you generates summary for that image for 32K and use it on 64K virtual 
> >erase block size that will not work.
> I think, this is better if you solve this inconsistency in general.

Yes.  The cumulation of erase blocks is an ugly ugly hack.  The fact
that vmalloc() of more than 128M will always fail doesn't imply that
vmalloc() of less will always succeed.  On i386 with 1GiB of ram and a
single kernel module loaded, the chance has already dropped to 0.

Now, "calculating" the erase block size such that we only vmalloc() a
bit less than 128M is an exquisitely bad idea.  It may work on some
machines, but will utterly fail on others.

The more I think about it, the more I believe that we have to remove
the vmalloc completely.  Anything else will still break at random,
depending on hardware, code like summary, moonphase and the taste of
your coffee this morning.

Jörn

-- 
Those who come seeking peace without a treaty are plotting.
-- Sun Tzu