[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: JFFS compression and hard links.

Johan Adolfsson wrote:

> We could consider the following as mount options instead of compile time
> options?
> And compression should of course only take place if it makes sense to do it,
> compressing .gif, .jpeg and .tgz might not be worth the effort.
> To consider: Should we always compress and then see if we should write the
> compressed or uncompressed version, or should the filesystem be "smart".

I think the e2compr model of allowing compression on a cluster basis is 
probably appropriate. Each cluster is compressed into ram and the size 
compared to the original size. If it doesn't meet the size contraint, 
the uncompressed data is stored. Trying to use file magic numbers or 
extensions can get you into trouble.

Another issue to consider is decompression buffer space. If you compress 
a whole file, you could need a good bit of buffer space, whereas if you 
limit the chunks that you're compressing to 32k-64k you can still get 
good compresion and don't have to worry too much about running out of RAM.
Joe deBlaquiere
Red Hat, Inc.
307 Wynn Drive
Huntsville AL, 35805
voice : (256)-704-9200
fax   : (256)-837-3839

To unsubscribe from this list: send the line "unsubscribe jffs-dev" in
the body of a message to majordomo@xxxxxxx.com