[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <1412059278.3904.8.camel@sauron.fi.intel.com>
Date: Tue, 30 Sep 2014 06:41:19 +0000
From: "Bityutskiy, Artem" <artem.bityutskiy@...el.com>
To: "richard@....at" <richard@....at>
CC: "dedekind1@...il.com" <dedekind1@...il.com>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"aschmidt@...aresearch.com" <aschmidt@...aresearch.com>,
"linux-mtd@...ts.infradead.org" <linux-mtd@...ts.infradead.org>,
"ricard.wanderlof@...s.com" <ricard.wanderlof@...s.com>
Subject: Re: [RFC] UBI bitrot checking
On Wed, 2014-09-24 at 00:06 +0200, Richard Weinberger wrote:
> This is a very initial draft for one possibility of bitrot checking in UBI.
> The basic idea is to have a worker function which reads a complete PEB and
> schedules scrubbing if bit flips are detected.
> Currently this check is triggered by accessing any UBI debugfs file (yes, I'm lazy!).
> We have to agree on an interface first.
> Do we want a debugfs file? Another ioctl()?
> Automatic in-kernel schedules?
> Of course this interface has to return EBUSY if currently a check is running...
>
> The current implementation has one limitation, it can only check PEBs which are used.
> As of now ubi_wl_scrub_peb() works only for used PEBs but I think we could change that.
Most probably we do want to give user-space some kind of control. At the
very least:
1. Whether the unflipper (or bitunrotter?) is triggered or not at all
2. When is it triggered
3. Whether the unflipper finished the job or not
4. For #3, it is preferrable that user-space has a possibility to wait
for an event, rather than poll. Should be easy to do with sysfs.
And no, not debugfs, this is not a debugging feature. Sysfs or, less
preferrably, IMO, ioctl.
Then, question - do we want user-space to have more control over the
unflipper, e.g., pause it and resume? E.g., if we are talking a critical
path, like a phone call on a phone, user-space may pause the unflipper
to make sure the phone UI latency stays within certain limits.
We need to consider various usage scenarios and make sure the interface
is suitable.
And we do not have to implement all the features, just make sure we can
add them in the future if needed.
--
Best Regards,
Artem Bityutskiy
---------------------------------------------------------------------
Intel Finland Oy
Registered Address: PL 281, 00181 Helsinki
Business Identity Code: 0357606 - 4
Domiciled in Helsinki
This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.
Powered by blists - more mailing lists