UBIFS automatic recovery

Richard Weinberger richard.weinberger at gmail.com
Fri May 13 02:11:44 PDT 2016


On Fri, May 13, 2016 at 10:47 AM, Johan Borkhuis <maillist at borkhuis.com> wrote:
> However, when I continue to pull the power on a system with a broken
> partition (without running the test-application, this is only started when
> all partitions are mounted correctly) after some time (this can be a few
> reboots, or a couple of 100 reboots) the system fixes the partition
> itself, and I can access the data again, without any indications in the
> log.

This should not happen. Either the UBIFS is broken and not mountable
or it can recover.
Something else seems to interact here.

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

> But the first time it succeeds again I get the following output when
> mounting:
> UBIFS: recovery needed
> UBIFS: recovery completed

This is perfectly fine and only indicates that UBIFS recovered
from an unclean shutdown.
i.e. replayed the journal.

> Now my question is if there is a process in the background that fixes the
> problem. If this is the case, how can I trigger or help this process, so
> that it will fix the problem on the first time the problem is detected.
>
> 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...

-- 
Thanks,
//richard



More information about the linux-mtd mailing list