JFFS2 space behavior when adding data to a file

[Jörn Engel]

On Fri, 10 June 2005 11:16:37 +0300, Caj Nordstrom wrote:
> 
> I have found a strange behavior for space usage when adding small data
> to an existing file. In my test I have used Intel/STM Nor flash with
> several mtd versions and currently mtd-snapshot-20050516.tar.bz2. The
> processor environment is arm7.
> 
> The problem is that far too much space is used when adding data a little
> at a time to a file. In my tests done with the included test program the
> results are the following when df shows around 1.4M free space at start.
> 
> 115k in each file for WITH_FLUSH or WITH_OPEN_CLOSE enabled
> 350k in each file without the options.
> 
> When coping directly the 115k file there are space for 162 files!!!!
> Totally around 18M data compared to 575k WITH_FLUSH.
> 
> Is this a known feature or bug?

Hmm.  This is pretty much expected behaviour.  Not wanted, but at
least expected.

Basically, jffs2 much more efficient when writing data in large
chunks.

Case 1: 4096 writes appending a single byte to a file.
Jffs2 will write a struct jffs2_raw_inode for each individual write,
containing the full header plus a single byte.  That should be
4096 * (68+1) = 282624 bytes in total.

Case 2: A single aligned write of 4096 bytes.
Jffs2 will compress the data, gaining maybe 50% by that.  It will
write a struct jffs2_raw_inode plus the compressed data.  That should
be 68 + (4096 * 50%) = 2116 bytes.

So, depending on compression ratio, case 2 will be about 100 times
more efficient than case 1.

For completeness, you write in chunks of about 20 bytes.  So here goes
Case 3: 204 writes of 20 bytes each.
Jffs2 will compress the data.  Short amount of data usually don't
compress well, but let's still assume we save 50%.  Adding the
headers, we get 204 * (68+10) = 15912 bytes.

So your testcase will be 8 times less efficient than aligned writes of
4096 bytes.

Jörn

-- 
Unless something dramatically changes, by 2015 we'll be largely
wondering what all the fuss surrounding Linux was really about.
-- Rob Enderle