mounting jffs2

[Artem B. Bityuckiy]

Sergei Sharonov wrote:
> Hi,
Hello :-)

> That's what I was afraid of. Looks like JFFS2 is not very usable on 
large
> NAND chips. Will the situation improve if the 200 MByte file
> is split into, say, multiple 20 MByte files? I guess not..
Yes, it is an option. Some thing will be much better. If you formulate 
specific questions, I may try do get concrete answers.

> 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?

> 2. Try YAFFS. Can anybody offer an opinion ;) ? 
> JFFS2 is well supported, every resonable question or problem is followed 
> up within hours. What about YAFFS? I also have a feeling that jffs2 has 
had 
> a bit more testing and larger user base. How mature is YAFFS?
I have no Idea. And I'd like to know this too :-)

> 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.

> I recall that
> initially summary was not created/updated dynamically, e.g. it was not 
> usefull for log data. Is it still the case?
No, it isn't.

> 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.

> 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'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.


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