jffs2 performance

jffs2 performance

[Alexander Neundorf]

Hi everybody,

on my job we're building an embedded device using the ecos operating system 
which comes with optional jffs2 support.
We need to be *very* fast on startup. I read different things about jffs2 
regarding performance.
We are using a Intel XScale processor 200 Mhz, with a 16 MB flash, from which 
8 MB will be used for jffs2 (or whatever we decide to use).
The file system will contains about 10 to 20 files. One very small file (4..20 
bytes) which is written very often, some intermediate files which are written 
only very seldom, and a big file consisting of approx. 1000 entries each 500 
to 2000 bytes large, the single entries written often. We could also use 1000 
small files each containing just one entry, but I guess this would be slower.

So what performance can I expect, especially how long will mounting approx. 
take (approx. 0.1 s or 1 s or 10 s) ?

I guess writing one (1000 byte) entry to an open file should be quite fast,  
<<0.1 s.

Can you give me some pointers ?

Thanks
Alex

P.S. I'm not subscribed, so please put me in the CC
-- 
Work: alexander.neundorf@jenoptik.com - http://www.jenoptik-los.de
Home: neundorf@kde.org                - http://www.kde.org
      alex@neundorf.net               - http://www.neundorf.net

Re: A couple of questions

[David Woodhouse]

adilos2@yahoo.com said:
>  -> Under what license it is released. My boss wants to
>  know if he would have to pay in order to put JFFS2 in our product.

Under what licence is your product? JFFS2 is under a dual licence - both 
GPL for compatibility with the Linux kernel, and RHEPL for use in eCos. 

>  -> We are using a flash device with different sector sizes ( 1*32k,
> 2*16k,1*64k and the others are 128k ), What size should the JFFS2
> reserved sectors have then ? 

128KiB - the 'major' erase size.

>  -> If JFFS2 is used without enabling compression, will there still be
> corner cases in GC requiring 5 reserved sectors and not 2. 

Probably not. To be honest, it probably wouldn't happen even _with_ 
compression - I just don't like releasing software that'll 'probably' work 
:)

>  -> Why can't JFFS2 be used on Compact flashes ? 

Technically, it can - we now have a 'blkmtd' driver which uses any block 
device as backing store for an MTD device - so it can use any hard drive. 
At the moment, it's painfully slow. Checkpointing ought to fix that, but 
nobody's currently working on implementing that.

--
dwmw2

JFFS2 performance

[Joakim Tjernlund]

Hi all

I am wondering how JFFS2 performance(primarly read performance) is affected by compression.
There are basically 3 types of (de)compression NONE, ZLIB and RTIME. Does it matter which
one is used w.r.t read performace?

 Joakim Tjernlund

Re: JFFS2 performance

[dennis noermann]

On Wed, 10 Oct 2001, Joakim Tjernlund wrote:

> Hi all
>
> I am wondering how JFFS2 performance(primarly read performance) is affected by compression.
> There are basically 3 types of (de)compression NONE, ZLIB and RTIME. Does it matter which
> one is used w.r.t read performace?

i am using ZLIB , and it is slow :(
on a mpc823 with 66Mhz with 2 Intel 28F320 interlaced (32 Bit) with
kernel 2.4.2 it takes 70 seconds to mount a 8Mb uge jffs2 Partition :(

an the read a write actions are slow :( ...

but a 640k partition is mountet realy fast :)

dennis