Re: [ECOS] Stress testing JFFS2

[Øyvind Harboe <oyvind dot harboe at zylin dot com>]

W.r.t. actual usage of JFFS2, here are the "parameters" for our usage:

- We need a capability to persit options(i.e. various named parameters 
that are anything from a couple of bytes to a couple of k in size).
These parameters are updated frequently during configuration phases and
only read during normal operation. The total number of files is ~10-30.
This configuration JFFS2 image is 6x64k. Possible alternative: Redboot
parameters?
- The configuration parameters are only read during startup. Afterwards,
it would be advantagous to flush all ram that JFFS2 is using. JFFS2 can
evidently rebuild the ram nodes more than quickly enough.
- During production we have a phase where the a second JFFS2 image is
modifyable(where we store, e.g. serial number). This JFFS2 image is
afterwards write protected in hardware. This JFFS2 image is 1x64k, hence
my previous posts about tricks to get JFFS2 to deal with this. Romdisks
could have been an alternative here, but the tools are designed to run
on the developer machine.

The needs above could be covered by other solutions. However, I like
JFFS2, because it is a generic solution.

I think the complete lists of tweaks to JFFS2 that I've had to do are:

- add option to disable compression. Saves ram. Flash is "cheap".
- allow JFFS2 to write to image when there are 0 free sectors. Allows
"ROM" scheme above + it fixes bugs that showed up in stress testing of
the 6x64k JFFS2 configuration image.
- GCC bug-fix. (Now comitted to eCos CVS, I think).
- Reboot after a couple of writes to JFFS2 to free up ram.


Ãyvind



-- 
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss