JFFS3 & performance

[David Woodhouse]

On Sat, 2005-01-22 at 16:03 +0300, Artem B. Bityuckiy wrote:
> 2. Worse, compression impacts JFFS2 design globally. You know, that the
> maximum amount of data JFFS2 may store in one inode node is the size of
> RAM page, most often 4K. 
> 
> Q: Why we restrict ourself with this size? 
> A: Because of compression.

It's not just compression that restricts us to 4KiB. Compressing in
larger chunks isn't hard -- zisofs does it, for example. The real
problem is the larger buffers you need for garbage collection. It's not
impossible to fix that though.

We've always intended to have a per-inode attribute for user-specified
compression parameters; the most basic of which would be 'no
compression'. I originally intended to expose those as attributes in the
way that 'chattr' works, with an ioctl on the file -- but I suspect
xattrs would be a better approach nowadays.

Compression has other drawbacks though -- if you throw out compression
you can do fixed-size records, you can have a block-based architecture
and simplify your metadata, ...

-- 
dwmw2