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 (Артём Битюцкий)
_______________________________________________
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel
