On 02/18/2013 04:34 PM, Charles Manning wrote:
> On Saturday 16 February 2013 11:30:43 Steven Hein wrote:
>> I've had a situation where NAND blocks are being marked bad
>> invalidly due to a HW/driver issue, and I am trying to recover them.
>>
>> I've patched the MTD code to allow bad block erase, and I've
>> the scrounged together a MEMSETGOODBLOCK ioctl patch to
>> allow bad blocks to be unmarked in the BBT. All of this is working:
>> I can erase bad blocks (and verify that data and OOB are all 0xff's),
>> and I can unmark the blocks bad in the BBT.
>>
>> When I have a YAFFS2 filesystem that has bad blocks, I use this
>> sequence to attempt to recover the blocks:
>>
>> (1) unmount the filesystem
>> (2) erase the bad blocks
>> (3) unmark the blocks bad
>> (4) mount the filesystem
>>
>> After this sequence, I have found that I have files in the
>> filesystem that are corrupted or missing, but they were
>> correct before I started the sequence.
> Adding erased blocks to a yaffs partition should not cause any problems so
> long as you mount without the scheckpoint, thus forcing a rescan to find the
> erased blocks.
>
> I suspect your procedure might not be working properly. Sometimes drivers will
> not erase a bad block.
>
> Try changing the order:
> unmount,
> unmark then erase bad blocks.
> check that the block really is erased
> remount.
>
> -- Charles
Thanks Charles! Checkpointing was the issue.
If I mount with "no-checkpoint-read" after the erase, then my
FS is intact.
Other than longer mount times, is there any other down side to
using no-checkpoint-read? Would you expect the non-checkpointed
mount delay to be significant for a 256MiB filesystem on a 2K block
NAND device (size 512MiB)?
Thanks, Steve
(text/plain)