From: Jamie Lokier <jamie@shareable.org>
To: Steve Finney <saf76@earthlink.net>
Cc: linux-mtd@lists.infradead.org
Subject: Re: NAND read errors, R/O FS
Date: Thu, 11 May 2006 00:28:09 +0100 [thread overview]
Message-ID: <20060510232808.GA1778@mail.shareable.org> (raw)
In-Reply-To: <16539078.1147288371389.JavaMail.root@elwamui-little.atl.sa.earthlink.net>
Steve Finney wrote:
> >On Wed, 10 May 2006 15:20:44 +0400, Vitaly Wool wrote:
> >> Josh Boyer wrote:
> >>
> >> >Not quite the case. You need bad block skipping, yes. But NAND can
> >> >get bit flips in good blocks still. How do you deal with that? You
> >> >can't leave the block in that state forever because it will continue
> >> >to get bit flips and then your data will be unusable.
> >> Yep, I know about the issue. The recommended way to go here AFAIK is to
> >> mark the block as bad and copy its contents to a free one.
>
> FWIW, on the Samsung K9F* NAND chip, the explicitly recommended
> procedure for single bit read errors is to do single bit Error
> Correction (assuming ECC is implemented) and to NOT remap (you _are_
> supposed to remap and copy one write errors). Apparently the chances
> of a 2nd bit error within a single 512 byte page (the ECC unit) are
> negligible.
Surely after observing one bit error, that doesn't reduce the
probability of observing another one later? I'd expect the bits to be
independent.
In other words, is it not the case that, _after_ observing a single
bit error, the probability of observing another bit error is exactly
the same as the probability of observing the first one was, before it
was observed?
-- Jamie
prev parent reply other threads:[~2006-05-10 23:28 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-05-10 19:12 NAND read errors, R/O FS Steve Finney
2006-05-10 19:20 ` Josh Boyer
2006-05-10 23:28 ` Jamie Lokier [this message]
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=20060510232808.GA1778@mail.shareable.org \
--to=jamie@shareable.org \
--cc=linux-mtd@lists.infradead.org \
--cc=saf76@earthlink.net \
/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