multiple MTD partitions

[Artem Bityutskiy]

ext Walter Bender wrote:
>> but unfortunately have not got feedback, and I suspect one of the reasons is
>> that it is too difficult to boot UBIFS on XO.
> 
> I think you would be well served by making it clearer to people what
> the goals are of UBIFS relative to existing systems, such as JFFS2, on
> the XO. This may motivate more people to both do the testing and it
> may help better focus the feedback.

Well, because the mail was _not_ an announcement of a new FS which is ready to 
be used in production, I sent the mail to the _devel_ mailing list, mostly for 
the people who know JFFS2 limitations, and who really need something better.

But you are right, let me put the things from the userspace developers' 
perspective.

Here are UBIFS goals:
=====================

1. Better scalability
2. Fast write speed

Goal 1 was not fully achieved - we need UBI2 for this. But to compare:
  * JFFS2: XO boots from about 1m 10 secs (when you have freshly flashed FS 
image) to ~ 4 minutes when your NAND flash is almost full
  * UBIFS: XO boot time is 1m and this does not depend on what you have on your FS

Note, I did not include the time which the bootloader takes, IOW, I started 
counting time from the moment when the white screen disappears.

On OLPC, UBI takes 2 seconds to attach flash, and UBIFS takes ~ 0.2 seconds to 
mount.

Vs. goal 2: UBIFS write speed is about 70MiB/second, because of the write-back 
support. IOW, UBIFS is similar to traditional FSes like ext2, which have 
internal buffers and make writes fast. To compare, JFFS2 write speed on XO is 
about 1.3 MiB/s, because it is always synchronous.

At the moment, JFFS2 beats UBIFS on synchronous writes. This is partially 
because JFFS2 is incorrect (it does not sync write-buffer on each write in case 
of O_SYNC-opened files - we've just discovered this), and partially because of 
some mistakes in UBIFS which we are going to fix.

Here are JFFS2 drawbacks I thought developers know about:
=========================================================

1. Long mount time, which depends on what you have in your file system.
2. Big files are opened for long lime - create a 300MiB file, reboot, and try 
'time stat file'.
3. Huge dependency on
4. 100% CPU usage my jffs2_mtd0 thread for about a minute after mount
5. Slow writes
6. Limited mmap support: MAP_SHARED is not supported.
7. It is easy to kill JFFS2-based system with a command like:
    dd if=/dev/zero of=file - it will run out of RAM at some point and the 
system will die at some point.

None of these drawbacks are present in UBIFS, at least on XO. Well, there is 
some price you have to pay - amount of available flash space is about 5% less 
then in case of JFFS2.

Other advantages of UBI/UBIFS stack
===================================

1. You may enable/disable compression on per inode basis. E.g., if you have an 
mp3 file, it makes zero sense to try to compress it, and you disable compression.

2. UBI gives you dynamic volumes, just like LVM. And you do not have to have 
one huge "/" partition which takes whole flash - you may have different volume 
for different stuff. This makes SW update easier - e.g., you do not have to 
backup "/home".

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