public inbox for linux-mtd@lists.infradead.org
 help / color / mirror / Atom feed
From: Artem Bityutskiy <dedekind@infradead.org>
To: Ricard Wanderlof <ricard.wanderlof@axis.com>
Cc: "Jörn Engel" <joern@logfs.org>,
	"Linux mtd" <linux-mtd@lists.infradead.org>
Subject: Re: Some news for this: [PATCH] [MTD] BLOCK_RO: Readonly Block Device Layer Over MTD ?
Date: Fri, 23 Nov 2007 10:18:24 +0200	[thread overview]
Message-ID: <1195805904.3231.87.camel@sauron> (raw)
In-Reply-To: <Pine.LNX.4.64.0711230836240.523@lnxricardw.se.axis.com>

Hi Ricard,

On Fri, 2007-11-23 at 08:42 +0100, Ricard Wanderlof wrote:
> In the case of mtd, it would seem that this should be done by JFFS2, or if 
> some intermediate layer is used like UBI, by that layer. As far as I know 
> though, currently no scrubbing is done by either?

Nope, scrubbing was one of the design goals of UBI and it does do it.

If mtd_read() returns -EUCLEAN, which means a correctable ECC error
occurred (bit-flip), UBI schedules this physical eraseblock for
movement. Then it moves it in background, re-maps corresponding logical
eraseblock to the new physical eraseblock, and schedules the old
physical eraseblock for erasure.

-- 
Best regards,
Artem Bityutskiy (Битюцкий Артём)

  reply	other threads:[~2007-11-23  8:18 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-11-21 14:27 Some news for this: [PATCH] [MTD] BLOCK_RO: Readonly Block Device Layer Over MTD ? Gregory CLEMENT
2007-11-21 16:08 ` Jörn Engel
2007-11-21 16:28   ` Gregory CLEMENT
2007-11-21 16:58     ` Josh Boyer
2007-11-21 17:07       ` Gregory CLEMENT
2007-11-21 17:13         ` Josh Boyer
2007-11-21 17:15       ` Jörn Engel
2007-11-21 17:32         ` Gregory CLEMENT
2007-11-21 17:43         ` Vitaly Wool
2007-11-21 17:45           ` Jörn Engel
2007-11-21 17:56             ` Vitaly Wool
2007-11-21 18:04               ` Jörn Engel
2007-11-23 14:35               ` Gregory CLEMENT
2007-11-23 14:45                 ` Jörn Engel
2007-11-23 15:06                   ` Gregory CLEMENT
2007-11-21 20:46       ` Ricard Wanderlof
2007-11-21 21:32         ` Jörn Engel
2007-11-21 22:33           ` Gregory CLEMENT
2007-11-21 22:54             ` Jörn Engel
2007-11-22  7:58               ` Ricard Wanderlof
2007-11-22 13:26                 ` Jörn Engel
2007-11-23  7:42                   ` Ricard Wanderlof
2007-11-23  8:18                     ` Artem Bityutskiy [this message]
2007-11-23  9:08                       ` Ricard Wanderlof
2007-11-23  9:21                         ` Artem Bityutskiy
2007-11-23  9:28                           ` Ricard Wanderlof
2007-11-23 18:40                             ` David Brown
2007-11-26  9:42                               ` Ricard Wanderlof
2007-11-26 13:58                                 ` Claudio Lanconelli
2007-11-23  8:19                     ` Artem Bityutskiy
2007-11-23 12:46                     ` Jörn Engel
2007-11-22  7:58           ` Ricard Wanderlof
2007-11-22 13:08         ` Jamie Lokier

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=1195805904.3231.87.camel@sauron \
    --to=dedekind@infradead.org \
    --cc=joern@logfs.org \
    --cc=linux-mtd@lists.infradead.org \
    --cc=ricard.wanderlof@axis.com \
    /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