mtd/fs/jffs2 erase.c,1.84,1.85 roll back

[Artem B. Bityutskiy]

Hello,

Anders Grafstrom wrote:
> Artem Bityutskiy wrote:
>> Index: erase.c
>> ===================================================================
>> RCS file: /home/cvs/mtd/fs/jffs2/erase.c,v
>> retrieving revision 1.84
>> retrieving revision 1.85
>> diff -u -r1.84 -r1.85
>> --- erase.c    20 Sep 2005 14:27:34 -0000    1.84
>> +++ erase.c    20 Sep 2005 14:53:15 -0000    1.85
>> @@ -337,7 +337,6 @@
>>              if (*datum + 1) {
>>                  *bad_offset += i;
>>                  printk(KERN_WARNING "Newly-erased block contained 
>> word 0x%lx at offset 0x%08x\n", *datum, *bad_offset);
>> -                ret = -EIO;
>>                  goto fail;
>>              }
>>          }
> 
> 
> May I ask why you rolled back this change?
No problems :-)

> I have a problem, that I'm trying to solve, with blocks that are not 
> erased despite a "successful" return from c->mtd->erase(). The result of 
> this is a very broken filesystem when the blocks are reused. It seems to 
> me that the above rolled back change would prevent the filesystem from 
> being broken in this situation(?).

Let's analyse the situation.

JFFS2 issues the erase command, MTD returns OK, but the eraseblock does 
not contain all 0xFFs. Is this JFFS2's fault? No. this is driver's 
fault. The driver must not return success in this case. It must return 
an error.

And the check in JFFS2 that the eraseblock contains all FFs is *wrong*. 
That's not JFFS2's business at all. That's MTD's business. MTD 
guarantees that it either erases the eraseblock or returns error. My 
oppinion is that this check must go to MTD. Perhaps, you may embrace it 
by #ifdefs - this is the implementation detal.

So, JFFS2 does what it is not supposed to do at all. It slows down 
things by this. I wanted to remove the check, but dwmw2 loudly 
complained. He wants to be as reliable as it is possible.

Ok, now about the rollback. If we return -EIO, JFFS2 will mark the block 
as bad. Imagine your driver is broken, and the block is not actually 
bad. That's just driver. JFFS2 will mark nearly all eraseblocks as bad. 
What will you do next? In case of NAND, this assumes you're in trouble 
unless you have a list of real bad blocks.

So, this is why I rolled back. Probably the right approach will be to 
add such blocks to the JFFS2 in-RAM bad block list but not mark them as 
bad physically. But this is a distinct activity. I didn't explore this.

That "fix" slipped there accidentally. I didn't test it. So I removed 
it. If you are energetic enough, work this problem out please :-)

-- 
Best Regards,
Artem B. Bityuckiy,
St.-Petersburg, Russia.