Benchmarking JFFS2

[Jarkko Lavinen]

> I suspect your results are skewed, and can see two possible reasons.
> 1. The file system is getting progressively dirtier as your tests continue.
>    Perhaps you should take a complete snapshot of the flash when the file
>    system is 'dirty', and reinstall that precise image before each run.

It is quite laborious to flash a new file-system for each benchmark
run. Instead I added an option to make clean file-system dirty.

The program opens two files and fills the file-system writing these two
files in turns. The file A writes big blocks (about 2K) and is thrown
away once the file-system fills. The file B writes smaller blocks but
is left in place. Because the writes for the two files occurred in tuns
every erase block will have about 90% of garbage and small live data
pieces here and there. This dirtiness is reproducible and but perhaps even
too dirty and artificial for benchmarking.

Rerunning the benchmark with this setup had dramatic result. You were
right. My results were badly skewed.

Now the write performance peak is 11300 B/s at 1024 byte block
size. After 4K block size the throughput drops close to 2KB/s. I have
included the gnuplot figure containing the previous result from clean
file-system and the new result from extra dirty file-system. 

During my benchmark runs I have encountered 'Eep. read_inode() failed for 
ino #...'. Is this something I should be concerned?

Jarkko Lavinen
-------------- next part --------------
A non-text attachment was scrubbed...
Name: combined.png
Type: image/png
Size: 3253 bytes
Desc: not available
Url : http://lists.infradead.org/pipermail/linux-mtd/attachments/20020503/047b6373/attachment.png