Testing JFFS2 using mtdram

Testing JFFS2 using mtdram

[Bernhard Priewasser]

Good morning,

I'm going to run some performance and stability testing on JFFS2. Using 
mtdram makes basic testing issues very comfortable. My question is how 
far mtdram can substitute a "real" flash (not for absolute measurement 
of course, only comparisons)?
Am I right with my first approach:
  read operations - yes
  write operations - no?

Regards,
Bernhard Priewasser

Re: Testing JFFS2 using mtdram

[Ferenc Havasi]

Hello Bernhard,

> I'm going to run some performance and stability testing on JFFS2.
> Using mtdram makes basic testing issues very comfortable. My question
> is how far mtdram can substitute a "real" flash (not for absolute
> measurement of course, only comparisons)?
> Am I right with my first approach:
>  read operations - yes
>  write operations - no?

mtdram emulates NOR flash (both read and write operations), but does not
emulate delays. You can test stability with it, but for performance I
suggest Artem's nand simulator. It's included in the official MTD. It
can emulate delays and ceratinly you can test the NAND functionalities
of JFFS2, too.

Ferenc

Re: Testing JFFS2 using mtdram

[Artem B. Bityuckiy]

Ferenc Havasi wrote:

> mtdram emulates NOR flash (both read and write operations), but does not
> emulate delays. You can test stability with it, but for performance I
> suggest Artem's nand simulator. It's included in the official MTD. It
> can emulate delays and ceratinly you can test the NAND functionalities
> of JFFS2, too.
Albeit you cannot emulate > 128 MB flashes (just because 128 MB is the 
vmalloc()'s limit). This may be fixed, I just did not bother. And I 
never used that delays, just added them to make nandsim look cooler 
(kidding) :-)

-- 
Best Regards,
Artem B. Bityuckiy,
St.-Petersburg, Russia.

Re: Testing JFFS2 using mtdram

[Jörn Engel]

On Mon, 22 August 2005 12:58:25 +0400, Artem B. Bityuckiy wrote:
> 
> Albeit you cannot emulate > 128 MB flashes (just because 128 MB is the 
> vmalloc()'s limit). This may be fixed, I just did not bother.

I did that for ramtd.  Allocate an array of pointers and then lazily
allocate memory for those pointers.  Moves the limit to 128G on i386.
For even bigger flashes, a 2-3 level tree would work, but I rarely
need more than a gig.

Jörn

-- 
Invincibility is in oneself, vulnerability is in the opponent.
-- Sun Tzu

Re: Testing JFFS2 using mtdram

[Bernhard Priewasser]

 > I did that for ramtd.  Allocate an array of pointers and then lazily
 > allocate memory for those pointers.

Did anyone do something similar for mtdram too?
I tried it quick & dirty, but didn't work :-) If there's a solution for 
mtdram I would be grateful, otherwise I had to try further. 
mtdram's/vmalloc()'s total size limit indeed is rather low for extensive 
testing.

Regards,
Bernhard

Re: Testing JFFS2 using mtdram

[Jörn Engel]

On Tue, 23 August 2005 16:47:34 +0200, Bernhard Priewasser wrote:
> 
> > I did that for ramtd.  Allocate an array of pointers and then lazily
> > allocate memory for those pointers.
> 
> Did anyone do something similar for mtdram too?
> I tried it quick & dirty, but didn't work :-) If there's a solution for 
> mtdram I would be grateful, otherwise I had to try further. 
> mtdram's/vmalloc()'s total size limit indeed is rather low for extensive 
> testing.

Ramtd was supposed to replace mtdram.  There were the usual problems
with parameter parsing, and writing a new one was easier than fixing
the old.

Jörn

-- 
He who knows that enough is enough will always have enough.
-- Lao Tsu