Re: Does UBI LEB-level access interlock happily with UBIfs access?

[Richard Weinberger <richard@nod.at>]

Am 22.09.2014 10:34, schrieb Ricard Wanderlof:
> 
> On Sat, 20 Sep 2014, Richard Weinberger wrote:
> 
>> On Fri, Sep 19, 2014 at 7:24 PM, Artem Bityutskiy <dedekind1@gmail.com> wrote:
>>> On Fri, 2014-09-19 at 13:17 -0400, Atlant Schmidt wrote:
>>>> But as I pointed, this will not force re-read of the volume table LEBs.
>>>> To address this, you'd need to do some additional, not very difficult
>>>> work.
>>>
>>> Oh, and this won't make UBI re-read the EC and VID headers, so they may
>>> bit-rot too.
>>>
>>> So indeed it sounds like UBI needs a separate interface for this kind of
>>> "scrub all bit-flips" issues. I do not think it is hard to do - all the
>>> mechanisms are already implemented, so this would mostly be about
>>> inventing good API.
>>
>> We could implement a trivial knob to trigger such a check in kernel.
>> I.e. you trigger the check via an ioctl() or whatever and UBI schedules
>> such a read-check for every PEB into the UBI background thread.
> 
> During the scanning operation that takes place when a partition is attached, doesn't this also trigger a check of all headers, as all the data needs to be read as part of the
> ubiattach process?

Only headers will be read.
And with fastmap enabled only very few of these headers are read.

> Not that that would be a practical solution for many systems where it is not practical to detach and re-attach, for instance the partition where the root volume is located, as that
> would in practice require a reboot.
> 
>> I'd volunteer to implement this.
> 
> I think it would be good if such a forced re-read could be set to happen automatically at a specified interval, say by default once a day.

cron can trigger that easily.

Thanks,
//richard