AW: Reading from UBI volume character device did not work.

[Stelling Carsten]

______________________________________
 Carsten Stelling
F&E Hardware / R&D Hardware

GÖRLITZ Aktiengesellschaft | August-Thyssen-Straße 32 | D-56070 Koblenz
T: +49-261-9285-336 | M:  | F: +49-261-9285-190
Mail to: Carsten.Stelling at goerlitz.com | www.goerlitz.com

Vorstand | Executive Board: Dipl.-Ing. Norbert Bartsch, Jörg Figge
Vorsitzender des Aufsichtsrates | Chairman of the supervisory board: Norbert Wagner
Registergericht | Court of registration: Amtsgericht Koblenz HRB 5346
Sitz der Gesellschaft | Registered office: Koblenz
Immer up-to-date mit unserem Newsletter! Hier geht's zur Anmeldung: www.goerlitz.com/newsletter
Member of the IDS-Group

-----Ursprüngliche Nachricht-----
Von: Richard Weinberger [mailto:richard.weinberger at gmail.com]
Gesendet: Mittwoch, 8. Juli 2015 21:30
An: Stelling Carsten
Cc: linux-mtd at lists.infradead.org
Betreff: Re: Reading from UBI volume character device did not work.

Hi Carsten,

On Wed, Jul 8, 2015 at 8:27 PM, Stelling Carsten
<Carsten.Stelling at goerlitz.com> wrote:
> Hello,
>
> I'm trying to read from a UBI volume using the character device /dev/ubi2,
> but read always returns 0. My kernel version is 3.14.31 (no ubiblock).
>
> fd = open("/dev/ubi2", O_RDONLY);
> read(fd, buffer, count);
>
> I set count to different values, especially to min_io_size = 2048, but without success.
> Reading from the underlying MTD device "/dev/mtd8" succeeds.
> What did I miss?

read() should return -1 with errno = EINVAL as you cannot read from /dev/ubi2.
read/write access is only implemented for volume devices like /dev/ubi2_X.

> My task is, as suggested by the UBIFS documentation, to write a userspace daemon
> on top of UBI, that reads all LEBs and associated PEBs in the background, to let UBI
> handle rarely accessed pages with accumulated bit-flips.

Please note that this check is not perfect.
You'll miss all pages which contain UBI meta data like EC/VID headers.

This reminds me that I should carry on with my bitrot patch set. B-)

--
Thanks,
//richard

Hi Richard,

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.

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

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.

I apologize for any inconvenience by polluting this list with my signature.
It is appended by our mail server automatically, and I cannot switch this off.

Carsten