State of read-only filesystems in NAND / MTD bad blocks handling when reading

[Ricard Wanderlof]

On Fri, 4 May 2012, Thilo Fromm wrote:

>>  It contains a maximum of m-fudge_factor LEBs (Logical Erase Blocks)
>>  of n-ovehead pages each. It can erase whole LEBs, write pages, and
>>  read pages. By providing bad block mapping and wear leveling, it
>>  provides a device which is slightly smaller than the MTD device
>>  it's layered upon, but that device doesn't have bad blocks and
>>  you can't wear out any individual LEB faster than the whole
>>  device wears out. The device remains perfect until its reserve
>>  of replacement (spare) blocks is exhausted as blocks go bad.
>
> But unfortunately I can use these features with nothing else than UBIFS?

Well, you can use it for large binary objects, such as the Linux kernel, 
if you want. There are currently no other filesystems other than ubifs 
which run directly on top of UBI, but if you enable the gluebi layer, you 
get mtd devices on top of each ubi volume so you can use jffs2 if you 
want.

Gluebi is in many cases not really an option, because it maps _each_ ubi 
volume to an mtd device, thus you cannot for instance mix jffs2 and ubifs 
on a gluebi system. AFAIU it would be possible to extend gluebi so that it 
would be possible to enable the gluebi layer only for selected ubi 
volumes, but AFAIK it has not been done (yet).

Technically I suppose one could device a "jffs2a" to run directly on a UBI 
device, but it would be rather pointless; we have a "jffs3" which turned 
into ubifs in the end.

While jffs2 is tried-and-tested there is very little development and 
maintenence going on nowadays, with development and bug fixing instead 
going into ubifs. So over time, jffs2 will probably tend to degrade while 
ubifs will continue to improve.

>>  UBIfs (on top of UBI on top of MTD) "materializes" a file system.
>>  It contains ordinary Linux/Unix files on a perfect storage medium.
>>  It depends upon the perfect storage provided by UBI.
>
> I have the impression that we took a shortcut between the last two
> paragraphs. Can you please elaborate on why i need a second UBI
> partition within an UBI partition in order to use UBIFS? Or am I wrong
> with this point?

I think you've misunderstood something.

Basically, if you have an mtd partition, say mtd2, then you can attach UBI 
to it (or is the terminology 'attach an mtd partition to UBI'; I'm not 
sure):

# ubiattach -m 5 /dev/ubi_ctrl

/dev/mtd2 --> /dev/ubi0

Within each UBI partition, you can then have several volumes, e.g.:

# ubimkvol /dev/ubi0 -N kernel -s 3 MiB -t static
# ubimkvol /dev/ubi0 -N rootfs -s 25 MiB -t static
# ubimkvol /dev/ubi0 -N appdata -s 55 MiB -t dynamic

/dev/mtd2 --> /dev/ubi0 --> /dev/ubi0_0
                         +-> /dev/ubi0_1
                         +-> /dev/ubi0_2

In each volume you can have a file system, i.e. ubifs, which can be 
mounted:

# mount -t ubifs ubi0:appdata /usr/apps

/dev/mtd2 --> /dev/ubi0 --> /dev/ubi0_0 --> kernel blob
                         +-> /dev/ubi0_1 --> /
                         +-> /dev/ubi0_2 --> /usr/apps

In the simplest case, you can just have one volume in your UBI partition:

/dev/mtd2 --> /dev/ubi0 --> /dev/ubi0_0 --> /usr/apps

But yes, there are two devices, one representing a whole partition under 
UBI control, and the other one representing a volume. The underlying mtd 
device also still exists. But it's not really stranger than having a 
classic hard drive, with e.g. /dev/sda as the 'base' device for the drive, 
and /dev/sda1 and /dev/sda2 for the partitions, while also having a 
/dev/sg1 for certain operations.

/Ricard
-- 
Ricard Wolf Wanderlöf                           ricardw(at)axis.com
Axis Communications AB, Lund, Sweden            www.axis.com
Phone +46 46 272 2016                           Fax +46 46 13 61 30