MLC Support in JFFS2

[massimo cirillo]

Hi,
I agree with you, and the following is my thinking.
Let's suppose we have a flash with 2KB page, 128KB block,
4096 blocks (512MB as size of the flash).
The cleanmarker would take one page for every block, so the
wasted space is 2KB*4096=8MB. Instead if we put the erased
info in a single block (TOKEN_BLOCK) we waste only 128KB.
But we need to consider the overhead in the management of
such a block. We need to store information for 4096 blocks,
for example an array of 4096 bit (1=erased, 0=not erased),
protected by ECC (against read error) and CRC (against
power loss in writing the array on the block). We need 2 pages
for each instance of the array. The question is: how often do we
need to update this array? If we choose to update each time it is
needed (that is when a block is  just erased and just before a block
is taken from the free list), at the 32nd update we should erase the
TOKEN_BLOCK and allocate a new one. IMO this overhead is
unacceptable in terms of time performance. So we update the info
only at the unmount and when the system is idle.
Moreover, there is the problem of power loss between two updates:
how to recognize at the mount that the array info is updated? In my
opinion the solution is to write an invalidation mark (one page with
all zeros) just after the instance of the array when the instance
becomes invalid.

Bye

2010/4/9 Amul Kumar Saha <amul.saha at samsung.com>:
> Hi,
>
>
>>Ok,
>>but at the remount how do you verify if the TOKEN_BLOCK
>>is updated or not (in case of power loss) ? I suggest using
>>a commit mark (one page wasted) at the end of the update
>>procedure.
>>So you'll have in the TOKEN_BLOCK the following layout:
>>
>>MAGIC_NUMBER of the TOKEN_BLOCK
>>ready_to_use info
>>commit mark
>>
>>What do you think ?
>>
>
> Yes.
> However, the TOKEN_BLOCK update would then
> only be limited to mount and unmount.
> As writing a commit mark while the system is still running,
> would validate an invalid block on abrupt power-off.
>
> Regards,
> Amul
>
>
>