Nandwrite's behavior in case of write failure
nahor.j+gmane at gmail.com
Fri Jun 5 22:40:35 EDT 2009
Artem Bityutskiy wrote:
> On Thu, 2009-06-04 at 18:23 -0700, Nahor wrote:
>> 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
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.
More information about the linux-mtd