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

[Matthieu CASTET]

Thilo Fromm a écrit :
> Hello, Richard,
> 
> [ MTD read might return bad blocks ]
>>>> One way is to use a file system intended for flashes, but mount it
>>>> read-only. I.e. use a jffs2 filesystem, mounted readonly.
>>>
>>> Yupp, or I coud hack up SquashFS to be bad blocks aware. However, it
>>> feels kind of wrong to me to leave bad block handling to the file
>>> system layer. Because I would have to provide bad block awareness to
>>> every read-only FS I am planning to use. Over and over again.
>>
>> I principally agree, however, jffs2 is doing just that, managing bad blocks.
>> Whether that is a good idea or not is debatable of course. Technically it
>> mixes up file system and device properties. Also, you might not plan to
>> change read-only FS's very often so the effort might be quite minimal in
>> practice.
> 
> It still feels like the wrong place to do this. Every FS would just
> skip this block, and be done with it.

There also bit-flip handling that ubi manage, but other fs don't handle.
And with newer nand, bit-flip happen sooner.

> 
> Apart from the fact that my NAND SW stack will then be two layers
> higher than it actually needs to be (and the added complexity this
> brings to boot loader and kernel) -  as far as I know UBI does not
> provide the functionality we require: being able to store a read-only
> file system image, and mount it at boot time. At least we don't get
> this without another boot step (initrd, see above).
> 
gluebi + mtdblock_ro doesn't work ?



Matthieu