From: Artem Bityutskiy <dedekind1@gmail.com>
To: Mike Frysinger <vapier@gentoo.org>
Cc: linux-mtd@lists.infradead.org
Subject: Re: [PATCH] nandwrite: add --nobad to write bad blocks
Date: Mon, 13 Sep 2010 09:23:10 +0300 [thread overview]
Message-ID: <1284358990.27765.154.camel@localhost> (raw)
In-Reply-To: <AANLkTinkp3O9uFhumuuBTq4T+Um9MSjFv3nb_byF0Q35@mail.gmail.com>
On Sun, 2010-09-12 at 15:05 -0400, Mike Frysinger wrote:
> On Sun, Sep 12, 2010 at 12:27, Artem Bityutskiy wrote:
> > On Sat, 2010-09-11 at 23:51 -0400, Mike Frysinger wrote:
> >> Sometimes dumping bad blocks is useful, like when the block isn't actually
> >> bad but the OOB layout isn't what the kernel is expecting or is otherwise
> >> screwed up. The --nobad option allows just that.
> >
> > How useful is this? I think instead you should implement the force flag
> > we discussed and deal with 'otherwise screwed up' eraseblocks with
> > flash_erase. I am afraid it is too dangerous to introduce this option.
>
> i dont see how this is any more dangerous than adding an option to
> force erasing of bad blocks ? why should we be over protective of the
> system ?
Because it was like this for long time and people are accustomed to the
fact that if a block is marked as bad, nothing will happen to it.
Besides, if I misuse options and lose a really bad block, it is very
difficult to find it again.
> this is what got is into the existing rut of unrecoverable
> blocks.
>
> i find it useful during development to write out the content of pages
> irregardless of the bad blocks and then read them back.
But if a block is marked as bad, the current contents of it is not
necessarily 0xFFs and it does not necessarily ready to be written. You
have to first erase it.
So my point was - please, first provide the means to erase them.
> and for
> recovering systems manually without having to resort to local access
> to the bootloader.
> -mike
--
Best Regards,
Artem Bityutskiy (Артём Битюцкий)
next prev parent reply other threads:[~2010-09-13 6:24 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-09-12 3:51 [PATCH] nandwrite: add --nobad to write bad blocks Mike Frysinger
2010-09-12 16:27 ` Artem Bityutskiy
2010-09-12 19:05 ` Mike Frysinger
2010-09-13 6:23 ` Artem Bityutskiy [this message]
2010-09-14 1:21 ` Mike Frysinger
2010-09-14 5:26 ` Artem Bityutskiy
2010-09-22 4:23 ` Mike Frysinger
2010-09-22 7:12 ` Artem Bityutskiy
2010-09-22 7:34 ` Mike Frysinger
2010-09-29 3:35 ` Iwo Mergler
2010-09-29 6:56 ` Jon Povey
2010-09-29 13:25 ` Mike Frysinger
2010-09-29 23:44 ` Iwo Mergler
2010-09-30 3:23 ` Jon Povey
2010-09-29 12:59 ` Artem Bityutskiy
2010-09-29 13:28 ` Mike Frysinger
2010-09-30 3:51 ` Jon Povey
2010-09-23 1:48 ` Jon Povey
2010-09-23 10:38 ` Artem Bityutskiy
2010-09-23 20:04 ` [PATCH v2] " Mike Frysinger
2010-09-24 8:50 ` Artem Bityutskiy
2010-09-24 12:33 ` Mike Frysinger
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=1284358990.27765.154.camel@localhost \
--to=dedekind1@gmail.com \
--cc=linux-mtd@lists.infradead.org \
--cc=vapier@gentoo.org \
/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).