UBIFS errors when file-system is full

[Bhuvanchandra DV]

On 07/22/2015 12:50 PM, Richard Weinberger wrote:

> Am 22.07.2015 um 09:10 schrieb Bhuvanchandra DV:
>> On 07/21/2015 11:44 AM, Richard Weinberger wrote:
>>
>>> Hi!
>>>
>>> Am 21.07.2015 um 08:04 schrieb Bhuvanchandra DV:
>>>> Ran the power cut tests with fm_debug enabled, no additional logs are observed.
>>>> After few hundred power cuts U-Boot fails to mount with -22 and kernel fails
>>>> mounting with stack trace when reading the node.
>>> Why U-Boot? Has U-Boot fastmap enabled?
>> Yes, fastmap is enabled in U-Boot.
> Please disable it.

Disabled fastmap in U-Boot, still the corruption is persistent when using
U-Boot to mount rootfs and load kernel.

>> The same power cut tests are done by skipping the U-Boot to mount the UBIFS. Loaded
>> the kernel via tftp and mount the rootfs with kernel. The power cut test passed.
>> I think U-Boot might have some issues, but not very sure.
> To my knowledge U-Boot's fastmap support is incomplete.
> If you *really* need fastmap in U-Boot make sure that they have backported
> all recent fastmap changes. Fastmap is still experimental and faced a lot of fixes
> recently.

Tested with mainline U-Boot along with few downstream patches for boot config block
support applied, the ubifs corruption is persistant.

>
>>> Anyway, we need to sort out what is going on.
>>> As fm_debug does not trigger it could also be a non-fastmap issue.
>>> Did you try your test without fastmap being enabled?
>>>
>>> Does your target pass UBI tests too?
>> I'm not aware of UBI tests so far the driver passed all MTD tests.
>> Can you please provide some pointers for UBI tests. Will run the UBI tests with
>> driver.
> They are in the mtd-utils source.

Not yet ran the ubi-tests. Will run the tests and share the results.

>
>>>> Log:
>>> [...]
>>>> [    2.847326] UBIFS error (ubi0:0 pid 1): ubifs_read_node: bad node type (255 but expected 3)
>>>> [    2.866839] UBIFS error (ubi0:0 pid 1): ubifs_read_node: bad node at LEB 981:70368, LEB mapping status 1
>>>> [    2.887961] Not a node, first 24 bytes:
>>>> [    2.891864] 00000000: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff                          ........................
>>> Hmm, LEB1 is unmapped.
>>> If you disable fastmap, does this target boot as expected?
>>> Or is this a persistent corruption?
>> No, the corruption is persistent.
>> - removed|fm_autoconvert from kernel args - removed the fastmap support from kernel Tested with above both cases, the corruption is persistent. |
> Okay that is a clear hint that Linux's fastmap is only the messenger and not the evil doer.
>
> Thanks,
> //richard

Best regards,

Bhuvan