sergei.sharonov at halliburton.com
Thu Apr 14 10:15:36 EDT 2005
> > 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
> > 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
What would be a time frame for a stable JFFS3 solution assuming there is a
> > 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?
More information about the linux-mtd