On Mon, Jul 14, 2008 at 6:19 PM, Chris Ball <[EMAIL PROTECTED]> wrote:
> 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.
+100
Most data that gets into the journal is already compressed: PNG, OGG,
PDF (some), ODT, XO, XOL, etc.
How would this work? Should we create an empty file, set an xattr and
then start writing? If so, we should think about how we can modify all
sw to do so. Alternatively, as in most cases data is already
compressed, perhaps would be better to not compress by default - or
let that process to zip the file with gzip :P.
If jffs2 can check if the first block compresses and stop doing it if
it doesn't, that may be best.
Regards,
Tomeu
_______________________________________________
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel
