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

[Thilo Fromm]

Hello Ricard,

>>>  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.

That's a bit much. What do I gain from a kernel in mtd/UBI instead of
putting it directly into a plain MTD?

> 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).

Ah, okay.

> 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.

And I think you did some excellent work with the UBI/UBIFS stack. It's
the way to go when you need a flash-aware r/w fs. The drawback is that
handling and maintenance of UBI filesystems is still a bit "special"
(as in: things don't work like they do with other, more generic, file
systems). And one side effect of this "specialness" is that you're
currently seem to be limited to the MTD/UBI stack and can't use other
file systems on MTDs.

> 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.

Concerning flash-aware read/write file system stacks I totally agree
with your opinion about UBIFS vs. JFFS2. It would clearly be UBIFS for
me if I would have to choose a flash-aware r/w FS stack. But I don't
need read-write. I don't even need a file system. I just need a r/o
block device that works for mounts.

>>>  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

Thanks for the walktrhough. However, there are two things I don't like
here: I must use the r/w block layer ubi0, and I'm limited to one
specific (r/w !) FS - ubifs - on top of that.

> 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.

I beg to differ :)
HDD device nodes and partition device nodes work much more like
MTDBLOCK and the MTD "partitioning" layer. Basically all they to is
mapping relative offsets (partition-based) to absolute offsets
(chip-based). The only obvious difference imho is that the HDD
partitioning driver does not hide the original device.

Regards,
Thilo

-- 
Dipl.-Ing (FH) Thilo Fromm, MSc., Embedded Systems Architect
DResearch Fahrzeugelektronik GmbH
Otto-Schmirgal-Str. 3, D-10319 Berlin, Germany
Tel: +49 (30) 515 932 228   mailto:fromm at dresearch-fe.de
Fax: +49 (30) 515 932 77    http://www.dresearch.de
Amtsgericht: Berlin Charlottenburg, HRB 130120 B
Ust.-IDNr. DE273952058
Geschäftsführer: Dr. M. Weber, W. Mögle