public inbox for linux-mtd@lists.infradead.org
 help / color / mirror / Atom feed
From: Nahor <nahor.j+gmane@gmail.com>
To: linux-mtd@lists.infradead.org
Subject: Re: Nandwrite's behavior in case of write failure
Date: Fri, 05 Jun 2009 19:40:35 -0700	[thread overview]
Message-ID: <4A29D723.1010109@gmail.com> (raw)
In-Reply-To: <1244205087.5847.66.camel@localhost.localdomain>

Artem Bityutskiy wrote:
> On Thu, 2009-06-04 at 18:23 -0700, Nahor wrote:
>> Hi,
>>
>> If the call to pwrite fails, nanwrite tries first to erase the block 
>> then to mark it as bad. If erase fails, nandwrite aborts. If setting the 
>> bad block flag fails, nandwrite just ignores it and go to the next block.
> 
> I think this is a bug. It should not aborts in erase fails, but mark
> the block as bad instead. But it should check the error code as well,
> and mark it as bad only if the error was EIO. I.e., it should not
> mark the block as bad on ENOMEM.
> 
> And yes, if mark_bad() fails, nandwrite should not ignore this.
> 
> This is what we do in ubiformat, I think. Also, ubiformat asks the user
> if he wants to mark the block as bad, unless the -y option was used.
> nandwrite could do something similar.

nandwrite has the -m/--markbad option instead of -y.
However, if the option is not set, the blocks are skipped without being
marked. I guess nandwrite should either ask the user or fail immediately.
Continuing seems useless.


>> My questions are:
>> - Why erase the block?
> Just in case. We should be very careful with marking blocks as bad,
> because if you do this by mistake, you may loose your device. Indeed,
> imagine you marked 100 blocks as bad my mistake, and you do not remember
> the block numbers. How will you know which blocks you should then
> unmark?

Well, one could unmark all of them and run nandtest, then flog oneself and
swear to pay more attention next time :)

More seriously, in my case, I want to use nandwrite for automatic updates
so I prefer that it marks too many blocks bad than have the update abort
because nandwrite wants to be conservative and exits instead of flagging
the offending block and continuing.


> So the idea of erase is to check whether the block is really bad
> or this is just a driver bug or something.

Do you mean that if the erase succeeds, nandwrite shouldn't mark the block
bad and just exit?

I'm not too familiar with the NAND technology but it is not possible that
a block can be erasable but not written to? At least nandtest thinks so, it
mark blocks as bad on either erase or write failures.

And so does ubiformat. flash_image() either exits or marks the block
bad if mtd_write fails. It doesn't try to erase it first.


	Nahor

  reply	other threads:[~2009-06-06  2:40 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-06-05  1:23 Nandwrite's behavior in case of write failure Nahor
2009-06-05 12:31 ` Artem Bityutskiy
2009-06-06  2:40   ` Nahor [this message]
2009-06-07  8:57     ` Artem Bityutskiy
2009-06-08 17:00       ` Nahor
2009-06-08 20:43       ` Jehan Bing
2009-06-09 12:59         ` Artem Bityutskiy

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=4A29D723.1010109@gmail.com \
    --to=nahor.j+gmane@gmail.com \
    --cc=linux-mtd@lists.infradead.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