UBIFS automatic recovery

[Richard Weinberger]

Johan,

Am 13.05.2016 um 12:27 schrieb Johan Borkhuis:
>> This should not happen. Either the UBIFS is broken and not mountable
>> or it can recover.
>> Something else seems to interact here.
> 
> This was also what I was expecting, and why I was surprised when units
> started to recover.

Maybe a temporary issue with your NAND.

>>> When it fails it shows the following during a mount (also shown
>>> sometimes for LEB 3 and 6):
>>> UBIFS: recovery needed
>>> UBIFS error (pid 640): ubifs_recover_log_leb: unrecoverable log
>>> corruption
>>> in LEB 5
>>>
>>> Another UBIFS message I see during a failed mount is:
>>> UBIFS error (pid 637): ubifs_recover_master_node: dumping first master
>>> node
>>>
>>> As long the mount fails the same message is repeated.
>>
>> UBIFS must not break due to power cuts.
>> So, something else is broken.
>> Do both MTD and UBI tests pass?
> 
> You mean the kernel startup? Or some specific MTD/UBI test tools?
> On startup there is no difference in the console-output between a good and
> bad startup, so MTD and UBI are initialised correctly. The first sign is
> the fact that a mount fails.

In the kernel tree we have a set of tests, MTD tests.
See CONFIG_MTD_TESTS.
UBI tests are part of the mtd-utils source package.

>>> Or is there another way to fix/repair a broken partition without loosing
>>> the data that is stored on it?
>>
>> No. What you need is figuring out *why* UBIFS breaks while doing
>> power cuts. Both UBI and UBIFS are power cut aware by design.
>> In most cases UBIFS suffers from MTD problems. May it a faulty driver
>> or bad hardware...
> 
> We are using a Micon 2Mb flash chip and the kernel sources from TI. The
> output during boot:
> omap2-nand driver initializing
> NAND device: Manufacturer ID: 0x2c, Chip ID: 0xca (Micron )
> Creating 6 MTD partitions on "omap2-nand.0":

*maybe* a driver issue.
First of all you need to find out what exactly is broken.
i.e. analyze the contents of the NAND upon failure.

Thanks,
//richard