compr_zlib.c

Joakim Tjernlund Joakim.Tjernlund at lumentis.se
Tue Mar 19 13:55:21 EST 2002


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. 

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

What is the maximum amount of data JFFS2 will try to compress in one go? I am
thinking of adjusting  windowBits and memLevel, now they default to 128 KB each which
seems a bit too much.

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?


       Jocke

On Tue, 19 Mar 2002, Joakim Tjernlund wrote:

> No comments so far.
> Anyone?

Looks good. Suspect we should make it a new compression type instead, and 
fix the mount routine to check for compression types we don't support, 
like we check for node types we don't support.

-- 
dwmw2







More information about the linux-mtd mailing list