mtd-utils/nandwrite: what if write fails?

[Artem Bityutskiy]

Hi Richard,

On Tue, 2006-10-17 at 16:17 +0200, Ricard Wanderlof wrote:
> I have a question regarding writes to NAND flash; for instance, in 
> mtd-utils/nandwrite.c, prior to writing to a block, it is checked so that 
> it isn't bad (using the MEMGETBADBLOCK ioctl). However, what happens if 
> the block goes bad during write? If the pwrite() call which writes out the 
> page data fails, the application says perror() and exits. Shouldn't it 
> mark the block as bad, and re-write the data so far written to the block 
> to the next good block? 

If we are talking about nandwrite - I would prefer it not to do this. Or
do this if an this was specified via an explicit option ...

> As I understand it, mtd doesn't mark a block bad,

Yes, MTD provides you mechanisms to do this, but it is up to you (MTD
user) to do this or not.

> it is up to the application or overlying file system (e.g. JFFS2).

Yes, not only JFFS2, just any software which works on top of MTD and
knows what it does. For example, UBI can do this. Or some user-space
tools.

>  So it 
> won't even help to run nandwrite again as the block has not been marked 
> bad.

Not sure, put probably yes. You may explore fix this adding a
corresponding option to nandwrite. Or you may write an utility which
does flash torturing and identifies bad eraseblocks, e.g., flash_check.

> (Or is it simply that normally nandwrite is only used during testing, or 
> writing an initial filesystem, and the likelyhood of a block failing at 
> precisely this time is rather small, compared to the rest of the lifetime 
> of the memory (i.e. repeated JFFS2 accesses)?)
Not sure, but I personally used it only for debugging purposes.

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