Re: mounting jffs2

[Sergei Sharonov <sergei.sharonov@halliburton.com>]

Hi,

> > Other possibilities that I would like to investigate:
> > 1. Partition NAND into two blocks.
> We usually call flash sector "block", so I am confused what do you mean. 
> Just split your flash on 2 partitions?

Sorry, I meant two partitions. (blocks is sense of /dev/mtdblock ;)

> > 2. Try YAFFS. Can anybody offer an opinion ;) ? 
...
> I have no Idea. And I'd like to know this too 

It looks like I would need YAFFS2 in order to handle 2 kB pages. And it is
pretty new. Also the traffic is definitely lower on yaffs list.

> > 3. Try summary patch. How stable is it with jffs2? Is anybody using it
> > in production or is it still pretty much experimental?
> AFAIK, it is quite good.

That is good to know. Thanks.

> > 4. Combine (1) with (3). (1) will give fast write access, (3) hopefuly 
> will
> > give fast read access????
> You'll end up with quick mount, but the "touch your_200mb_file" command 
> (just after mount) should be still be slow. touch your_20mb_file will be 
> ~10 times faster.

I'll run a test with 10x20 MByte files and post results.

> > 5. Look for a commercial solution. I recall somebody was talking at 
> > Embedded Conference about porting their filesystem to linux.
> May be. The other case is just to start developing JFFS3. We have some 
> ideas.

What would be a time frame for a stable JFFS3 solution assuming there is a 
support?
 
> > What's the point in having a big NAND if you cannot fill it ;) ?
> JFFS2 wasn't designed for such large flashes/files. It has scalability 
> problems. And you can fill it if you're ready to spend a lot of RAM/time.

Got 32 MB, can probably go to 64 MB. Will that be sufficient to support 
256 MB NAND assuming 1 kB writes? BTW, does it make sense to increase write 
size above 1 page (2 kB). I understood from previous discussions that jffs2 
will split it on a page boundary anyway?

Sergei Sharonov