Re: compr_zlib.c

[David Woodhouse <dwmw2@infradead.org>]

Joakim.Tjernlund@lumentis.se said:
> OK, a new compression type will be cleaner. What should be done with
> compression types  not supported? Can't say that I understand the
> logic behind the unsupported nodes. 

I think we should mount the filesystem read only. We're going to get I/O 
errors on parts of files that we can't decompress.

> What do you think about STREAM_END_SPACE? Should it be changed to
> something bigger? 

STREAM_END_SPACE is supposed to be the amount of space we need at the end 
of the output buffer to sync up and complete the output. I suspect we 
should just use a different limit for the minimum amount of data we'll 
bother to compress.

> What is the maximum amount of data JFFS2 will try to compress in one
> go? 

One page - normally 4KiB, sometimes 8KiB. I've been pondering changing that 
to get better compression but that might break compatibility so it'd have 
to be an obvious win.

> I am thinking of adjusting  windowBits and memLevel, now they
> default to 128 KB each which seems a bit too much.

Sounds reasonable. Would that mean we can also reduce the amount of memory 
preallocated for the deflate workspace, which is currently about 400KiB?

> Will you accept a patch against the stable branch?

> Also there has been a few performance improvements lately and I would
> like to see them in the stable branch as well. We are using them all
> and no problems so far. Any chance that will happen? 

I would rather not change the stable branch. That sort of defeats the 
object of having it in the first place. There are three types of changes in 
the trunk since that branch was taken:
	1. Cosmetic changes and code reshuffles for eCos portability.
	   These shouldn't affect functionality at all.
	2. NAND support, which shouldn't affect NOR flash adversely.
	3. The aforementioned performance enhancements.

If you want to use the performance enhancements, I'd rather you worked on, 
and tested, the trunk code. 

--
dwmw2