linux-mtd.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: Ricard Wanderlof <ricard.wanderlof@axis.com>
To: Mike Dunn <mikedunn@newsguy.com>
Cc: Peter Horton <phorton@bitbox.co.uk>,
	"linux-mtd@lists.infradead.org" <linux-mtd@lists.infradead.org>,
	Robert Jarzmik <robert.jarzmik@free.fr>,
	"dedekind1@gmail.com" <dedekind1@gmail.com>
Subject: Re: [PATCH v2] MTD: modify mtd api to return bitflip info on read operations
Date: Wed, 7 Dec 2011 09:01:40 +0100 (CET)	[thread overview]
Message-ID: <Pine.LNX.4.64.1112070848340.32119@lnxricardw.se.axis.com> (raw)
In-Reply-To: <4EDECC7A.1080202@newsguy.com>


On Wed, 7 Dec 2011, Mike Dunn wrote:

> For UBI, the direction of the discussion was that the driver would 
> indicate the ecc strength of the device (via a new element in struct 
> mtd_info), and this would be the default UBI scrublevel.  A non-zero 
> sysfs parameter would override the default.


>
> BTW, it is currently possible (and easy) to do what Peter suggests; i.e., to
> avoid any UBI rework and make the decision to scrub in the driver.  All the
> driver has to do is not return -EUCLEAN unless it thinks the block should be
> scrubbed.  Of course this would be a lie if there were in fact corrected
> bitflips.  For drivers using the mtd nand interface, the lie would be in the ecc
> stats, since the nand infrastructure code returns -EUCLEAN (or 0) based on
> that.  This is what we willl have to do in the diskonchip drivers in order to
> get ubi/ubifs to work on them if we don't change the mtd api (and afterwards
> make the changes to ubi).

The idea of using -EUCLEAN to indicate that the lower levels think it's 
time for scrubbing appeals to me. One reason is that an upper layer such 
as UBI should not really be concerned with details such as ECC strength 
and number of flipped bits, it seems to me that such things should be left 
to a lower level. Also, one could imagine different variants of flash 
technology requiring different consideration to bit flips and other 
phenomena which again should not be something that for instance UBI needs 
to know about. It makes sense for mtd to have a sweeping knowledge of the 
general types of errors that can occur so that part of the decision can be 
made there.

That said, the level at which the lowest level reports -EUCLEAN could be 
something that is configurable from user space (sysfs), so that it's 
userspace that sets the actual policy and no one else.

So, something like this:
- The driver reports number of bit flips and current ECC strength etc to
   the mtd layer.
- Based on some userspace knob, the mtd framework reports -EUCLEAN if
   scrubbing is needed.
- Upper layers perform scrubbing if they want to (i.e. UBI) or not (i.e.
   JFFS2).

I don't really see this as lying, more of a redefinition of what -EUCLEAN 
really means. The current behavior was invented when single-bit errors 
could be correct and nothing else, and furthermore such bitflips were 
rare; now that multiple-bit errors are commonplace it's time to put more 
detail into what -EUCLEAN implies.  It's not really breaking anything old 
either, if sane defaults are used.

/Ricard
-- 
Ricard Wolf Wanderlöf                           ricardw(at)axis.com
Axis Communications AB, Lund, Sweden            www.axis.com
Phone +46 46 272 2016                           Fax +46 46 13 61 30

  reply	other threads:[~2011-12-07  8:01 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-12-03 20:20 [PATCH v2] MTD: modify mtd api to return bitflip info on read operations Mike Dunn
2011-12-04  8:43 ` Peter Horton
2011-12-04 13:52   ` Mike Dunn
2011-12-04 14:43     ` Artem Bityutskiy
2011-12-04 14:55       ` Mike Dunn
2011-12-05  6:07         ` Artem Bityutskiy
2011-12-05 16:58           ` Mike Dunn
2011-12-05 17:09             ` Peter Horton
2011-12-05 18:57               ` Mike Dunn
2011-12-06 21:52                 ` Robert Jarzmik
2011-12-07  2:16                   ` Mike Dunn
2011-12-07  8:01                     ` Ricard Wanderlof [this message]
2011-12-07 18:32                       ` Mike Dunn
2011-12-12 12:48                         ` Artem Bityutskiy
2011-12-14 20:46                           ` Mike Dunn
2011-12-16 10:09                             ` Artem Bityutskiy
2011-12-07  9:42                   ` Peter Horton
2011-12-07 18:33                     ` Mike Dunn
2011-12-04 14:33 ` Artem Bityutskiy
2011-12-05  6:23 ` Artem Bityutskiy
2011-12-05 18:13   ` Mike Dunn
2011-12-05 21:16     ` Artem Bityutskiy

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=Pine.LNX.4.64.1112070848340.32119@lnxricardw.se.axis.com \
    --to=ricard.wanderlof@axis.com \
    --cc=dedekind1@gmail.com \
    --cc=linux-mtd@lists.infradead.org \
    --cc=mikedunn@newsguy.com \
    --cc=phorton@bitbox.co.uk \
    --cc=robert.jarzmik@free.fr \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).