choosing a file system to use on NAND/UBI

[Hamish Moffatt]

On Mon, Apr 07, 2008 at 03:15:34PM +0300, Artem Bityutskiy wrote:
> On Mon, 2008-04-07 at 21:20 +1000, Hamish Moffatt wrote:
> > 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?

My idea is that you can "ubiupdatevol /dev/ubi0_0 myimage.gz", which
ubiupdatevol would decompress on the fly. You could decompress it
somewhere first but it may not fit in RAM (and writing it to flash
temporarily would be slower).

Looking at the code I see the main issue is that you need to know the
file size before you start updating. I think this is possible with zlib
(flashcp needed to know the same).

Hamish
-- 
Hamish Moffatt VK3SB <hamish at debian.org> <hamish at cloud.net.au>