none
Flash compaction failed RRS feed

  • Question

  • Due to a high flash utilization, Windows CE compactor is starting to collect some "dirty" blocks. Unfortunatly I have noticed a problem where the block that has been selected for compaction can not be written on. In this case I receive following error message: [code] FLASHDRV.DLL:Compactor::GetNextCompactionBlock() Error: Cannot write to block 14! Unknown: DEBUGCHK failed in file C:\ymzki\private\winceos\DRIVERS\msflash\src\.\compactor.cpp at line 733 FLASHDRV.DLL:CompactorThread() - CompactorThread(0xffffffff) failed; unable to compact!!! [/code] In fact this block is marked with the Read-Only Flag (bOEMReserved & 0x2). In detail this block holds the MBR sector and it should no be selected for compaction anyway. In my opinion there is a bug in Compactor. Why does the method GetDirtiestBlock() check if the block is readable *after* the block has been selected? I think it might be more reasonable to check the read-only flash *while* the dirtiest block is getting searched for. Does anyone had similar problems with compactor? To resolve this situation I will try to mark all sectors in this MBR block as used.
    Tuesday, December 6, 2011 11:35 AM

All replies

  • It looks like a true bug.
    And have you applied up to date QFE? Perhaps a bug like this has been addressed?

    Wednesday, December 7, 2011 1:21 AM
  • I agree this looks like a bug, and a particulary nasty one in that the bootpart library marks the block that stores the MBR as read-only, and you will not notice this until the compactor runs and selects this block for compaction.

    Other code in the FAL does account for read-only blocks, see e.g. BuildUpMappingInfo(), so it would seem reasonable if the compactor were able to handle these by just skipping over them. This of course would mean that read-only blocks would never get wear-levelled, but this was the intention anyway according to a comment in bootpart.cpp.

    Tuesday, February 28, 2012 5:57 AM