LZO support

[Deepak Saxena]

On Jul 14 2008, at 12:19, Chris Ball was caught saying:
> Hi,
> 
>    > Based on some very provisional testing, I believe that the extremely
>    > long save times we're seeing in EToys are at least partly related
>    > to our use of zlib compression for data nodes in the filesystem.
>    > We could switch to LZO compression for a 500% speedup in
>    > compression (write), a 50% speedup in decompression (read), and a
>    > slight (but significant) decrease in compression ratio.
>    
> I prefer aiming at #2886 ("Some files shouldn't be compressed by
> jffs2"), which goes a long way to solving the user problems without
> introducing the logistical cost of LZO support in OFW or partitions.

I've been thinking about this a bit and there are all sorts of issues
involved here. The patches I know of that that exist to disable compression
on cramfs are for use at file system creation time, where we know exactly
what data we're stuffing into the system.  These are primarilly used
to disable compression on executables and allow XIP.

If we want to do this at runtime, we have to figure out how to tell the
the kernel not to compress a file?

- One option, as suggested in the trac, is to have the kernel trap file 
  extensions and disable compression based on that. Doable, but I expect 
  a rather large hack to VFS to do this. An extension to this idea is
  to look for specific signatures in files that disable compression.

- Another option is to provide a one-time flag passed at file creation
  time (O_CREAT) to enable/disable compression. This would also require
  VFS changes but I think would be simpler; however, this case has the
  problem that all applications that may at one time write a file that
  does not need compression need to be modified to support this extension.


> Saving a movie would be faster still than LZO if we could just tell
> jffs2 that we're giving it compressed data that it shouldn't recompress.

Do we have some idea of how much of our data in general is compressed
and how much is not?  If most our compressed data is small text files 
and the majority or our data is large compressed files, maybe we can
drop the compression requirement all together?

If we look beyond jffs2 and consider yaffs as an alternative (not upstream 
but has been actively used in the embedded world for years), it does no 
compression whatsoever at the filesystem level. 

~Deepak

-- 
Deepak Saxena <dsaxena at laptop.org>