Reading from UBI volume character device did not work.

[Richard Weinberger]

Hi Carsten,

On Thu, Jul 9, 2015 at 8:39 PM, Stelling Carsten
<Carsten.Stelling at goerlitz.com> wrote:
> Thank you for your hint. After creating the volume device with ubimkvol it works.
> You are right, this approach is suboptimal, since it covers approx. 96% of the
> available pages.

But it misses the most important ones. The pages containing the headers.
Especially if Fastmap is used these pages are not even read upon attach time.

> What's the timeline for your work on the bitrot patch?

When it is done, it is done.

> Additionally, here're some of my thoughts related to the crawler:
> The crawler process might be a very long running task of several days or
> even longer. This depends on the size of the flash and the CPU load allowed
> for this task.
> The background process should not introduce high CPU load (max. 2-3%,
> but short peaks for scrubbing may be ok).
> Thus, the user wants to control the speed of reading (idle time between
> subsequent page reads).
> It is ok for the background process to sequentially process UBI volumes.
> There must not exist one crawler thread per volume.
> The crawler should terminate itself in a clean way, without accessing the flash,
> if the device is switching to runlevel 6 (shutdown). Power fail conditions are
> handled by the low level flash driver, blocking write or erase operations (not
> to be handled by UBI).
> From time to time, the user might want to persist information about the actual
> volume and PEB the crawler is working on. This, in addition to the capability to
> set the PEB to start from, this can avoid repeated processing from start, if the
> device is powered off and on repeatedly. Otherwise, PEBs at the end would
> never be reached, read and scrubbed in the process.
> It would be great, if the user can determine the status of the crawler via sysfs
> or ioctl. sysfs might be better in the sense of event driven programs. Setting
> the starting point (volume and PEB) might be helpful as said above. Thus,
> the user can persist the actual crawler status, and set the starting point to the
> PEB by himself where processing was left off at shutdown.

Yeah, this is exactly what my big plan is.
I call it ubi-healthd.
All it needs is a proper kernel interface to check any PEB for
bitflips, schedule
re-write and gathering read/write counters.
Especially for MLC nand we need it.

-- 
Thanks,
//richard