Re: Nandwrite's behavior in case of write failure

[Artem Bityutskiy <dedekind@infradead.org>]

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.

> 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?

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

> - Probably linked to the first question, why abort if erase fails? Why 
> not just ignore it and rely on the bad block flag?
I guess this is a bug in nandwrite

> - Why ignore the bad block flag error? If nandwrite can't set it and 
> just goes on, the caller (app ou user) will think that everything is 
> good. But when reading the partition later, the user will garbage when 
> reaching that page.
And this must be a bug, IMO.

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