ubifs volumes vs. mtd partitions

Question

I'm migrating a product from jffs2 file system to ubifs.

Previous jffs2 design contains 3 mtd partitions ( 2 ro and 1 rw ) .

moving to ubifs - should I create :

• One mtd partition and 3 volumes
• 3 mtd partitions, 1 volume each

Basically I'm asking if I should replace partitions with volumes when moving to ubifs ? ( my understanding that ubi layer will manage entire flash if doing so )

Thanks, Ran

Uncovered

Answer 1

The options exist and here are the benefits...

One mtd partition and 3 volumes

The UBI layer will manage the volume. This is a flash virtualization layer that transforms unreliable flash into reliable memory. The UBI layer does wear leveling. Even for read-only data it is beneficial to re-write the data occasionally. This will recharge floating gates, etc so that the data remains readable for longer. For the read-write data it is highly beneficial for longevity. The UBI wear leveling will take place across all volumes. This substaneously increases the erase-write cycles that the file system can handle.

3 mtd partitions, 1 volume each

This is usually less desirable, but there are benefits and it maybe suitable to some users. Mainly having a separate partition increases reliability of mounting a single volume. If something happens to the single MTD partition, then your entire flash might become unuseable. By having seperate MTD partitions, a read-only MTD/UBI/UbiFS system may be useable when the read write filesystem failed.

This really is more beneficial for a 3rd option,

multiple MTD with mixed file systems.

It is possible to put CramFS, RomFS in some flash devices where a device block is gaurenteed reliable by a manufacturer. This maybe a boot file system that is all that is required for a system to minimally function. The tools for manipulating these partitions are quite simple (compared to UBI/UbiFS) and can be implemented in minimal code space. Some systems have large DDR with smaller on-chip SRAM. Loaders/flashes may have restricted code space.

That said, recently (last two years) the mtd-utils contains UBI parsing code. This might be need to be ported to a flasher, recovery code, etc. Recovery code might be in an attached initrd partition, which does mounting/fail-safe recover of the UBI/UbiFS partitions.

u-boot contains code to manage and manipulate UBI/UbiFS code and it use a two phase boot (running from internal SRAM, configuring DDR and then migrating) on many platforms to have rich functionality in a boot loader. u-boot itself will need to be on another device OR in a separate MTD as per above.

---

The 2nd option 3 mtd partitions, 1 volume each is probably the least likely/desirable. The first will favour system/flash life time. The last will offer simplicity of higher reliability/recovery. The best will depend on what the data is on the partitions and the non-linux resources you have available to recover data. The happy medium is to give as much NAND flash space as possible to UBI and use volumes when you want logical partitioning.

Usually, I would question why to use volumes at all and just put all the data together in such a case, but again it depends on the nature of the data.

Thirtythree

Thanks for detailed answer. I went with volume based design. – Uncovered

Generally the volume design is better if you have faith in the UBI/UbiFS stack. Some reliability depends on the MTD driver. If this fs stack doesn't fail (even with weird power cycling), then the volume design is always better. Only a battery powered design with fault tolerant requirements might need the partitions. Partitions are the way to go when developing an MTD driver. – Thirtythree

u-boot has very good ubi/ubifs handling (much improved since I wrote this answer) and, as always, storage capacities keep getting bigger every year. My 3rd option was for a secure imx258 chip where serial downloads or really limited SRAM (64K) was needed to load Linux. Since NXP has release tools for signing u-boot and everything needed for secure boot. So, maybe my option 3 is not as useful today. The bespoke boot loader was very fast from power to command line. – Thirtythree