MLC Support in JFFS2

[massimo cirillo]

yes,
the update only at the unmount and the usage of the commit
mark are ok for me.

2010/4/15 Raghav Gupta <raghav.gupta at partner.samsung.com>:
> Resending it due to formatting issues. My bad.
>
> 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.
>
>
> Yes, I agree with you. The overhead involved in updating the token block
> on every change in the "ready_to_use" list is unacceptable.
> So, we can update the TOKEN_BLOCK only at unmount.
>
> Also we can authenticate that the TOKEN_BLOCK as valid
> by using a "valid/invalid flag"(commit mark)
>
> And to guard against reading of an older version of
> a TOKEN_BLOCK (on power failure) as valid by immediately
> deleting the block on retrieval of the 'ready_to_use' list.
>
> Regards,
> Raghav Gupta
>
>
>