On Fri, Jun 11, 2010 at 8:51 AM, Andre Renaud <
andre@bluewatersys.com> wrote:
> Nick Bane wrote:
>>> Hello everyone,
>>>
>>> Question #1: I was told that UBIFS is better than Yaffs2, is that
>>> true? What are pros and cons?
>>> Question #2: It was said that Android 2.1 cannot use Yaffs2, is that
>>> true? If so, why?
>
> <snip>
>
>> These figures take no account of newer yaffs2 speed improvements, no
>> account of the degraded power security of cached writes and no account
>> of reliability issues surrounding not verifying nand writes. Verifying
>> nand writes is ok under ubifs but the header offsets must be page (not
>> sub-page) aligned until sub-page verifies are fixed in mtd. Using page
>> aligned headers which requires that userland ubifs utils must have
>> knowledge of the underlying nand architecture - ugh.
>>
>> My impression of running our applications on ubifs is that the write
>> speed and boot speed (especially without a clean unmount) is faster but
>> without the numbers to back it up this is only an impression. Installing
>> packages using dpkg (which makes many writes/moves) also seems much
>> faster. Overall reliability is far too early to judge.
>>
>> If someone can tell me how to do a git checkout without using long
>> unmemorable nubers I could redo this with a more modern yaffs2.
>
> I am curious as to whether these numbers, which seem to imply UBIFS is
> drastically faster than YAFFS (tar decompress 3x faster, dpkg 20% faster
> etc...) might be to do with using compression. The CPUs a lot of people
> are using now are pretty high end, and while NAND speed has improved, it
> is probably still quicker to compress data and thus write less of it.
>
I think the main reason UBIFS will do an untar faster is that it does
not write directly into flash.
UBIFS writes everything into RAM and then writes to flash in background.
If you do an untar with UBIFS and then kill power before the
background writing has happened you'll end up with a bunch of empty
files. You are not really measuring the write speed, just the caching
speed.
A far more realistic measurement is:
#untar ....; sync
> Has anyone ever looked at using LZO or similar compression within YAFFS
> to reduce the amount of data written?
This is something we talked about in very early YAFFS days. There are
some pros and cons.
Pros: Less writes, more stored.
Cons: Really bad for any form of overwrite (one of the main reasons
JFFS2 does not support memory mapped writing).
You can get some of the Pros by storing compressed files (eg. vai loop
mounting).
-- Charles
(text/plain)