From 45f2a2bc5b55fe15ae7ecafcb781a9076e78966c Mon Sep 17 00:00:00 2001 From: Daniel Drake Date: Mon, 10 Oct 2011 13:07:01 +0100 Subject: [PATCH] UBIFS FAQ: document reasons for loss of space efficiency OLPC is suffering a bit from the loss of space efficiency of UBIFS, document reasons for this based on an IRC discussion with Artem. Also document the difference in default compression schemes between JFFS2 and UBIFS which bit us at first. Signed-off-by: Daniel Drake Signed-off-by: Artem Bityutskiy --- faq/ubifs.xml | 58 +++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 58 insertions(+) diff --git a/faq/ubifs.xml b/faq/ubifs.xml index b6b0b14..e7aaa40 100644 --- a/faq/ubifs.xml +++ b/faq/ubifs.xml @@ -29,6 +29,7 @@
  • Does UBIFS support NFS?
  • Does UBIFS become slower when it is full?
  • Why df reports too few free space?
    • +
  • Why does my UBIFS volume have significantly lower capacity than my equivalent jffs2 volume?
  • How do I disable compression?
  • How do I use UBIFS with nandsim?
  • How do I extract files from an UBI/UBIFS image?
    • @@ -871,6 +872,63 @@ accurate is free space reporting.

    +

    Why does my UBIFS volume have significantly lower +capacity than my equivalent JFFS2 volume?

    + +

    When migrating a filesystem image from JFFS2 to UBIFS you may notice some +or all of the following:

    + +
      +
    • The size of the image file to be flashed is significantly larger + than before.
      • +
    • df reports significantly less available free space + than before (while there may be some truth in this, please be + aware of the other considerations that must be applied to + df values described elsewhere in this FAQ).
      • +
    • When measuring the capacity of the disk by seeing how much data + can be written, JFFS2 is able to store significantly more data than + UBIFS.
      • +
    + +

    There are several reasons for this.

    + +

    Firstly, did you create your volumes with default arguments to +mkfs.jffs2 and mkfs.ubifs? This alone introduces +a significant difference: mkfs.jffs2 effectively defaults to zlib +compression and disables lzo, but mkfs.ubifs defaults to LZO +compression. zlib compresses significantly better, but is noticeably slower to +compress/decompress at runtime. Using zlib compression with +mkfs.ubifs will probably reduce the size of your NAND image file +by 10-15%, put it on-par with an equivalent JFFS2 image, and increase the available capacity, at the price of performance.

    + +

    Secondly, did you choose a good value for vol_size or enable +autoresize in your ubinize configuration? It is possible that your UBI volume +is not utilising the full space of the available flash.

    + +

    Beyond that, it is unfortunately true that UBI/UBIFS has higher space +overhead than its predecessors. OLPC has +measured +this overhead to be approximately 50MiB per 1GiB of storage (using JFFS2 as a +baseline). While UBIFS cannot be made as good as JFFS2 in this respect, work +could be undertaken to improve space efficiency for current or future +UBI/UBIFS versions. Reasons for overhead and opportunities for improvement +include:

    + +
      +
    • For MTD controllers (such as CaFe) that do not support sub-page + writes, 2 KiB is taken from each eraseblock. If such controller drivers + were adapted (or hacked) to use software ECC for the first NAND page of + every eraseblock, around 8 MiB could be recovered per 1GB of + storage.
      • +
    • UBIFS on-flash data structures could be reduced in size. These + headers currently include many unused fields that are reserved for + future use.
      • +
    • UBIFS could be improved to reserve less space for internal needs, + but touching this part of the code is risky.
      • +
    + + +

    How do I disable compression?

    UBIFS compression may be disabled for whole file system during the image -- 2.50.1