All of lore.kernel.org
 help / color / mirror / Atom feed
From: Artem Bityutskiy <dedekind1@gmail.com>
To: Ricard Wanderlof <ricard.wanderlof@axis.com>
Cc: "Thorsten Mühlfelder" <muehlfelder@enertex.de>,
	"linux-mtd@lists.infradead.org" <linux-mtd@lists.infradead.org>,
	"Norbert van Bolhuis" <nvbolhuis@aimvalley.nl>
Subject: Re: Some questions on bit-flips and JFFS2
Date: Wed, 05 May 2010 11:51:20 +0300	[thread overview]
Message-ID: <1273049480.3702.129.camel@localhost> (raw)
In-Reply-To: <Pine.LNX.4.64.1005051039490.22753@lnxricardw.se.axis.com>

On Wed, 2010-05-05 at 10:40 +0200, Ricard Wanderlof wrote:
> On Wed, 5 May 2010, Norbert van Bolhuis wrote:
> 
> >> I've already thought about something like this:
> >> 1. After first succesful bootup dump a mtd0 image and calculate a md5sum of
> >> it:
> >> nanddump -o -b -f mtd0.img /dev/mtd0
> >> 2. Before each shutdown dump the image again and check if the md5sum has
> >> changed.
> >> 3. If it has changed write the initial dump back:
> >> flash_eraseall /dev/mtd0
> >> nandwrite -p /dev/mtd0 mtd0.img
> >>
> >> Would this be the right method?
> >
> > yes that's the idea, given that "refreshing" really helps to prevent
> > (actually delay) future read disturbs.
> > ...
> >
> > Another problem is a sudden reboot (e.g. crash or power-loss). There's 
> > no check then.
> 
> Also, if a power failure occurs during erase or nandwrite the system will 
> not boot next time.

Unless you supply your device with an UPS :-)

I did not really follow the discussion, so sorry if the following is
unrelated: I think it should not be too difficult to teach JFFS2 to
force GC on eraseblocks with bit-flips.

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

  reply	other threads:[~2010-05-05  8:52 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-05-03 13:05 Some questions on bit-flips and JFFS2 Thorsten Mühlfelder
2010-05-04  9:28 ` Norbert van Bolhuis
2010-05-04 14:59   ` Thorsten Mühlfelder
2010-05-05  8:34     ` Norbert van Bolhuis
2010-05-05  8:40       ` Ricard Wanderlof
2010-05-05  8:51         ` Artem Bityutskiy [this message]
2010-05-05  9:20           ` Ricard Wanderlof
2010-05-11  7:59             ` Thorsten Mühlfelder
2010-05-11  9:35               ` Ricard Wanderlof
2010-05-12 11:21                 ` Thorsten Mühlfelder
2010-05-12 12:22                   ` Ricard Wanderlof
2010-05-19  7:45                     ` Thorsten Mühlfelder
2010-05-05  9:29           ` Norbert van Bolhuis
2010-05-11  8:09       ` Thorsten Mühlfelder
2010-05-11 14:55         ` Norbert van Bolhuis
2010-05-12 10:48           ` Thorsten Mühlfelder
2010-05-05  6:59 ` Ricard Wanderlof

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=1273049480.3702.129.camel@localhost \
    --to=dedekind1@gmail.com \
    --cc=linux-mtd@lists.infradead.org \
    --cc=muehlfelder@enertex.de \
    --cc=nvbolhuis@aimvalley.nl \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.