Regarding UBI fastmap data CRC failure

[Ronak Desai]

On Wed, Mar 22, 2017 at 5:49 PM, Richard Weinberger <richard at nod.at> wrote:
> Ronak Desai,
>
> Am 21.03.2017 um 17:31 schrieb Ronak Desai:
>> On Mon, Mar 20, 2017 at 5:56 PM, Richard Weinberger
>> <richard.weinberger at gmail.com> wrote:
>>> On Mon, Mar 20, 2017 at 10:47 PM, Ronak Desai
>>> <ronak.desai at rockwellcollins.com> wrote:
>>>> Hi All,
>>>>
>>>> In one of the products with MLC NAND flash, we are using UBI
>>>> filesystem with kernel 3.12.
>>>
>>> MLC NAND is currently not supported.
>>
>> First of all, thanks for your response and your truly amazing
>> contribution in UBI.
>
> Thanks. :-)
>
>> I know that UBIFS requires a whole lot of changes to handle "program
>> disturb", "read distrurb" and "paired pages" problem on MLC NANDs.
>> But, apart from this, we have makesure that we use 256 wear-leveling
>> threshold.
>
> How do you handle paired pages?
> A powercut can still damage UBI and UBIFS.
>
We received patch-sets from Micron for paired page issue.
> [...]
>
>> That is true that our kernel is old but at this point and time it's
>> not a viable options for us to upgrade the kernel version. And agree
>> with your point about MLC but in months of use, we have seen this
>> continuous fastmap failure issue only once and apart from that UBIFS
>> works without any other issues.
>>
>> I see your changes on base fastmap implementation, which I am planning
>> to backport but it will be really difficult to backport the whole UBI
>> subsystem. So, if you can point to specific patches/changes to avoid
>> "fastmap data CRC failure" issue then it will be a great help.
>
> I fear it is not that easy. Fastmap saw many fixes and improvements
> other the time. The first version was rather buggy.
> And we made a stupid mistake at the beginning, we did not mark fixes
> for stable processing since Fastmap was considered
> as experimental. That's why you can't just backport all patches that
> have a stable tag.
> On the other hand, backporting the whole UBI subsystem is not that
> complicated. It has very few dependencies.
> U-Boot folks do this on a regular basis.
>
So, I found out a way to reproduce and fix it. If I powercycle around
the time when UBI performs recovery then it ends up with the CRC
failure issue and it can not recover from it. This behavior is with
3.12 kernel. Then I started patching UBI with the fixes related to
fastmap and fastmap WL, and got a state where UBI encounters the same
problem but on subsequent boot it recovers from it.

I need to perform more testing to finalize the changes though. I
appreciate your time for answering my questions.

Thanks,
Ronak

> HTH,
> //richard