Great jffs2 speedup

[Peter Grayson]

On Fri, 2005-09-30 at 21:15 +0000, Sergei Sharonov wrote:
> Aha!!! Of course, CS reduced your time to first write down to seconds.
> Could you repeat the test after the un-clean unmount (e.g. power off without
> sync)? I bet the numbers will be very different. Probably you also need to 
> be writing to flash during the power off to force full scan on startup.

I'll add this to my list of "things to try for the list".

> Hmm.. I was getting a read throughput jffs2 -> samba network fs of about 
> 1.1 MB/s (180 MHz ARM9, linux 2.6.10, mtd 3/28/2005). I believe jffs2/mtd 
> was the bottleneck since the throughput was 7.25x higher when files were 
> comming from ext2/RAM. Looks like your hw controller is doing a good job.
> Not sure how overhead is split between mtd and jffs2.

The mtd layer does not really introduce any overhead; it accounts for
the time it takes to get bytes in and out of the hardware. Jffs2, on the
other hand, has a number of aspects that use RAM and cpu cycles. Also,
the choices jffs2 makes affects how often it has to access flash.

> Tricky, tricky, tricky ;-)
> Not everybody is that lucky to have a battery. Reminds me of a conversation
> with one "high reliability RTOS" vendor, you guess who.
> - Is your file system power fail safe?
> - Yes, of course. We do require that you use UPS though.
> 
> > However, the thing to
> > remember about centralized summary is that in the unclean shutdown
> > cases, the mount time is no worse than jffs2 without CS. So even if you
> > only expect the filesystem to be cleanly unmounted sometimes, CS can be
> > worth it.
> 
> As long as specification allows for an "occasional" 30 minutes startup time.

Touche.

> Your hw controller does sound very interesting.
> What is the hardware implementation : asic, fpga? Is it available as a 
> separate product (chip)?

This is a soft core in an fpga. My company may be willing to license its
use.