public inbox for linux-mtd@lists.infradead.org
 help / color / mirror / Atom feed
From: Artem Bityutskiy <dedekind@infradead.org>
To: Nancy <nancydreaming@gmail.com>
Cc: linux-mtd@lists.infradead.org
Subject: Re: [RFC] slight UBI scan time improvement
Date: Wed, 23 Apr 2008 11:16:11 +0300	[thread overview]
Message-ID: <1208938571.11721.38.camel@sauron> (raw)
In-Reply-To: <bae050c10804230101m64bc2558icf9a5ad7efb8c824@mail.gmail.com>

On Wed, 2008-04-23 at 16:01 +0800, Nancy wrote:
>     Yes, the issue is go away by properly use MLC nand.
>     But the write fail issue in UBI still exist! Suppose you are
> properly used your Nand, when it return write fail, but can erase
> successfully, UBI still group this block in good block heap. That is
> wrong and dangerous.

The driver may return I/O errors for many reasons, including bugs in the
driver. Or this may be an dumb user who screwed up his flash. It might
be something else. We do not wand to mark the eraseblock bad when it is
_not_ bad.

And it's not just erase successfully. We torture the eraseblock. We
erase it, read it back, check it has all 0xFFs, then write 0xA5 pattern,
read it back, check, erase again, read back, check, write 0x5A pattern,
read back, check, erase, read back, check, write 0x00 pattern, read
back, check, erase, read back check. Enough? If it is not enough, feel
free to send a patch for better torturing.

Please, refer the torture_peb() function for more details.

So, we do not mark eraseblock as bad if it passed the torture test.
Note, a bit-flip during torture test is enough to mark the eraseblock
bad as well.

In your particular case, you would have _all_ eraseblocks marked as bad
if UBI did what you want.

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

  reply	other threads:[~2008-04-23  8:15 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-04-22 16:42 [RFC] slight UBI scan time improvement Artem Bityutskiy
2008-04-22 17:28 ` Bruce_Leonard
2008-04-22 18:07   ` Artem Bityutskiy
2008-04-23  7:15 ` Nancy
2008-04-23  7:32   ` Artem Bityutskiy
2008-04-23  8:01     ` Nancy
2008-04-23  8:16       ` Artem Bityutskiy [this message]
2008-04-23  9:07         ` Nancy
2008-04-23  9:13           ` Artem Bityutskiy
2008-04-23 10:51             ` Nancy
2008-04-23 10:57               ` Nancy
2008-04-23 12:24                 ` Artem Bityutskiy
2008-04-23 12:23               ` Artem Bityutskiy
2008-04-23  7:38 ` Hamish Moffatt
2008-04-23  8:13   ` Matthieu CASTET
2008-04-23  8:21     ` Artem Bityutskiy
2008-04-23  9:21       ` Matthieu CASTET
2008-04-23  9:27         ` Artem Bityutskiy
2008-04-23 12:40       ` Hamish Moffatt
2008-04-23 12:57         ` Artem Bityutskiy
2008-04-23 13:42           ` Hamish Moffatt
2008-04-23 14:09             ` Artem Bityutskiy
2008-04-24  1:53               ` Hamish Moffatt
2008-04-24  6:21                 ` Artem Bityutskiy
2008-04-24  7:02                   ` Hamish Moffatt
2008-04-24  0:10         ` Hamish Moffatt

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=1208938571.11721.38.camel@sauron \
    --to=dedekind@infradead.org \
    --cc=linux-mtd@lists.infradead.org \
    --cc=nancydreaming@gmail.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