choosing a file system to use on NAND/UBI

[Artem Bityutskiy]

On Mon, 2008-04-07 at 21:20 +1000, Hamish Moffatt wrote:
> Is that the CRC of one whole page of each block?

Only of the headers, which are 64 bytes.

> > I have 2 quick ideas about how to improve scan speed, but I am not sure
> > if they will help.
> > 
> > 1. Currently what UBI is doing is: read EC header, check it, read VID
> > header, check it. So we run mtd->read() 2 times (it might help to run it
> > 1 time because EC and VID headers go one after the other): read EC and
> > VID headers in one go, check them. We might do this soon.
> 
> How much is read each time - just a few bytes? Are those reads
> duplicated by the CRC check?

Well, NAND allows reading it PAGE_SIZE units. So it reads whole page.
Your flash allows sub-page write, so UBI reads 2KiB for per each
eraseblock. Then The your CPU is doing ECC check.

> > Well, the only way is to use mkfs.ubifs for this. You may create an
> > empty image, put it to the media and that's it. Would you conceive
> > something else?
> 
> I mean, I am preparing my root file system on my host and using
> mkfs.ubifs to generate an image which I write with ubiupdatevol. I found
> that zlib produced a smaller image.

That's right, zlib compresses better then lzo. But as I said, it is
slower, and reading files are slower, because de-compression is slower
in case of zlib.

> Also I found that the image can be compressed further with gzip or lzma.

Yes, because of several factors:
1. UBIFS (and JFFS2) does not compress meta-data.
2. UBIFS (and JFFS2) compresses 4KiB chunks of data independently.
Compression is better when you compress large chunks (which happens when
you use gzip or lzma), rather then small chunks.
3. The image has paddings, like paddings to the end of NAND page or to
the end of eraseblock. They also introduce more compressible data for
gzip.

> Could ubiupdatevol support on-the-fly decompression?
Err, why?

>  I will develop a
> patch if I have time.. I already patched flashcp to do this once.

Sorry, I am not sure what you mean here as well. What did your patch do?

-- 
Best regards,
Artem Bityutskiy (Битюцкий Артём)